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ABSTRACT 


PERSONNEL  AUTOMATION  PROBLEMS  DURING  OPERATION  DESERT  STORM 
by  MAJ  James  H.  Cornish,  USA,  124  pages. 

This  study  investigates  the  automation  problems  that  were 
encountered  in  support  of  personnel  accounting  and 
strength  reporting  during  Operation  DESERT  STORM.  This  is  of 
particular  interest  because  of  recent  efforts  to  offset 
force  structure  shortfalls  with  automation  initiatives. 
Operation  DESERT  STORM  was  the  first  conflict  to  put  those 
initiatives  to  test.  This  thesis  investigates  how  well 
personnel  automation  performed  during  the  Gulf  War  with  focus 
on  the  problems  needing  resolution. 

This  study  first  explains  the  personnel  automation  doctrine 
that  existed  at  the  time  of  Operation  DESERT  STORM.  The 
study  then  explains  how  personnel  automation  was  actually 
practiced  during  the  war  in  contrast  to  doctrine.  The  study 
then  describes  the  impacts  or  problems  that  resulted  from  the 
differences  in  doctrine  and  practice.  And  finally,  the  study 
presents  recommendations  of  how  to  address  the  personnel 
automation  shortcomings. 

With  an  understanding  of  the  problems  encountered  in 
Operation  DESERT  STORM,  the  personnel  community  may  now 
work  to  find  solutions.  Learning  from  these  problems,  the 
personnel  community  may  be  able  to  build  a  better  automated 
personnel  system  to  meet  the  challenges  of  tomorrow's  wars. 
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CHAPTER  1 


INTRODUCTION 

The  purpose  of  this  chapter  is  not  only  to  introduce 
this  thesis  but  also  to  provide  a  general  understanding  of 
it.  The  chapter  describes  the  nature  of  the  research 
question,  puts  the  thesis  into  perspective,  and  most 
importantly,  it  provides  overall  direction  to  the  thesis. 

Purpose 

The  purpose  of  this  thesis  is  to  identify  the  major 
automation  problems,  in  accounting  for  the  force  and 
reporting  unit  strengths,  encountered  by  the  personnel 
community  during  Operation  DESERT  STORM.  The  purpose  of  this 
thesis  is  not  to  provide  solutions  to  these  problems, 
although  some  general  recommendations  are  made  at  the  end. 

For  those  who  are  already  familiar  with  automation 
terminology  and  personnel  doctrine,  and  who  are  interested  in 
only  an  overview  in  terms  of  practical  effects,  may  want  to 
go  directly  to  chapters  G  and  7 . 

Background 

Over  the  past  five  or  six  years  the  Active  Army  has 
undergone  significant  changes  in  its  force  structure.  In  the 
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process,  the  Army  cut  many  spaces  from  personnel  units/organ¬ 
izations.  The  personnel  community  soon  realized  that  it 
would  have  to  depend  on  automation  initiatives  to  compensate 
for  the  loss  of  force  structure.  These  automation 
initiatives  would  be  especially  critical  during  wartime,  as 
units  would  be  unable  to  make  up  for  their  manpower 
shortfalls  with  Table  of  Distribution  and  Allowances  (TDA) 
augmentation,  or  shadow  clerks,  as  they  often  do  in 
peacetime.  Consequently,  the  personnel  community  has  focused 
its  efforts  on  increasing  its  automation  capabilities. 

Operation  DESERT  STORM  put  those  capabilities  to 
the  test.  When  Iraqi  forces  invaded,  seized,  and  occupied 
Kuwait  on  August  2,  1990,  nobody  really  knew  the  extent  to 
which  the  United  States  was  willing  to  go  to  ensure  the 
withdrawal  of  Iraqi  forces  from  Kuwait.  Eventually  the 
nation's  total  commitment  (all  services)  mushroomed 
to  a  force  of  more  than  527,000  and  included  more  than  1,200 
tanks,  more  than  2,200  armored  personnel  carriers,  more  than 
100  warships,  more  than  1,800  fighters,  bombers,  and  other 
warplanes,  and  more  than  1,700  helicopters.^ 

Naturally  the  Army  committed  the  major  share  of  the 
total  manpower.  On  August  6,  1990,  the  first  two  US  Army 
officers  landed  in  Saudi  Arabia  to  begin  organizing  for 
Operation  DESERT  SHIELD.^  By  the  time  the  Army  was  ready  to 
commence  ground  operations  during  Operation  DESERT  STORM 
there  were  306,700  soldiers  within  the  theater  of  operations. 
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Of  this  number,  230,800  were  members  of  the 
Active  Component;  36,800  were  members  of  the  National 
Guard;  36,300  were  members  of  the  USAR  [United  States 
Army  Reserve]  Troop  Program  Units  (TPU)  and  2,733 
were  Individual  Ready  Reservists.  Additionally,  six 
( 6 )... recalled  retirees  were  deployed.^ 

A  force  of  this  size  posed  many  challenges  for  the 
personnel  community,  from  mobilization  through  deployment, 
during  sustainment,  and  or  to  redeployment.  One  of  the 
biggest  problems  personnel  managers  had  to  address  was 
accounting  for  people  within  the  units  and  just  keeping  up 
with  the  aggregate  strength  of  the  force.  To  accomplish  this 
monumental  task,  personnel  managers  utilized  their  automation 
capabilities,  many  of  which  they  had  only  recently  acquired. 

This  thesis  describes  and  examines  the  major 
shortcomings  experienced  in  automation  support  for  the 
personnel  community  during  the  war.  It  also  gives  some  feel 
for  the  progress  made  in  automation,  since  the  personnel 
community  began  working  its  automation  initiatives  to  offset 
its  force  structure  shortfalls. 

Scope 

The  scope  of  the  thesis  does  not  include  automation 
as  it  supports  every  functional  area  of  personnel  management. 
Rather,  it  only  addresses  automation  support  of  accounting 
for  the  force  (personnel  accounting  -  defined  later  in  the 
chapter)  and  reporting  unit  strengths  (strength  reporting  - 
also  defined  later  in  the  chapter).  There  are  three  reasons 
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for  this.  First,  it  would  be  difficult  to  address  all 
personnel  functional  areas  within  the  confines  of  one  thesis. 
Second,  the  personnel  community  has  automated  only  the 
personnel  accounting  and  strength  reporting  areas  to  any 
significant  degree.  Finally,  all  other  personnel  functional 
areas  are  dependent  on  personnel  accounting  and  strength 
reporting  for  data. 

Additionally,  it  is  not  the  intent  of  this  thesis 
to  address  every  possible  problem  encountered.  Rather,  the 
intent  is  to  focus  on  those  problems  of  major  significance 
which  had  a  broad  impact  on  the  units  participating  in  the 
operation.  Thus,  this  thesis  focuses  on  only  the  universal, 
overriding  problems  while  screening  out  those  which  are 
either  symptomatic  of  the  major  problems,  or  are  of  minor 
importance.  The  thesis  shows  that  there  were  fundamental 
decisions,  policies,  and  system  shortcomings  which  created  a 
myriad  of  personnel  automation  problems  for  the  personnel 
community . 


Primary  and  Secondary  Questions 

This  thesis  answers  the  following  primary  and 
secondary  questions: 

Primary  Question:  What  were  the  major  personnel 
automation  problems  encountered  during  Operation  DESERT 
STORM? 
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Secondary  Question:  What  was  the  personnel 
automation  doctrine  at  the  time  of  Operation  DESERT  STORM 
(explained  in  terms  of  functionality,  software,  interfaces, 
hardware,  and  communications)? 

Secondary  Question:  How  was  personnel  automation 
actually  performed  during  Operation  DESERT  STORM  (explained 
in  terms  of  functionality,  software,  interfaces,  hardware, 
and  communications)? 

Secondary  Question:  What  were  the  impacts  or 
problems  that  resulted  from  the  differences  between  doctrine 
and  execution  (explained  in  terms  of  functionality,  software, 
interfaces,  hardware,  and  communications)? 

Assumptions 

Only  one  principal  assumption  was  made  in  the 
research  and  writing  of  this  thesis.  That  assumption 
is,  that  the  'lessons  learned’  reports,  after  action 
reports,  and  other  materials  examined  included  the  major 
problems  encountered  by  the  personnel  community  with  regard 
to  automation  support  of  personnel  accounting  and  strength 
reporting  during  Operation  DESERT  STORM. 

Definitions 

As  already  mentioned,  the  functional  focus  of  the 
thesis  is  on  strength  reporting  and  personnel  accounting. 
Strength  reporting  includes  the  management  of  and  accounting 
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for  the  force  on  a  numerical  basis.  Personnel  accounting  is 
the  actual  management  and  accounting  for  individual  soldiers 
on  a  by-name  basis.  Together,  personnel  accounting  and 
strength  reporting  account  for  soldiers  and  report  their  duty 
status.  This,  in  turn,  may  form  the  basis  for  critical 
battlefield  decisions.  Both  of  these  personnel  services 
interface  with  and  support  replacement,  casualty,  and  postal 
operations,  and  all  other  critical  personnel  services. 

Throughout  the  thesis,  the  term  personnel  automation 
is  used.  Personnel  automation  refers  to  the  automation  of 
personnel  functions,  such  as  casualty  reporting  or  preparing  an 
application  for  overseas  reassignment,  etc.  If  the  term 
personnel  automation  is  used  alone,  without  gualifying  a 
specific  personnel  function,  it  means  automation  in  support  of 
personnel  accounting  and  strength  reporting. 

The  thesis  describes  personnel  automation  doctrine, 
practice,  and  system  problems,  in  terms  of  functionality, 
software,  interfaces,  hardware,  and  communications. 
Collectively,  these  are  the  "component  parts  of  personnel 
automation . " 

Functionality  is  the  application  of  personnel  policies, 
procedures,  processes,  and  force  structure. 

Software  is  those  personnel  computer  programs  that 
support/automate  the  functionality.  Examples  include: 
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the  Standard  Installation/Division  Personnel  System  (SIDPERS) 
and  the  Command  and  Control  Strength  Reporting  System 
(C2SRS) . 

Interfaces  are  the  automated  means  which  allow  for  the 
exchange  of  data  between  software  systems.  Without 
interfaces  software  systems  cannot  share  or  use  each  other’s 
data . 

Hardware  is  the  computer  equipment  itself,  such  as:  the 
Tactical  Combat  Service  Support  Computer  System  (TACCS)  and 
the  Corps/Theater  ADP  Service  Center  (CTASC). 

Communications  refers  to  the  means  or  process  of 
electronically  transmitting  data  between  physical  locations. 

All  of  these  component  parts  make  personnel 
automation  work.  A  weakness  in  any  one  of  these  component 
parts  may  jeopardize  the  overall  effectiveness  or  utility  of 
personnel  automation. 


Limitations 

It  is  important  to  understand  the  limitations  of  this 
thesis.  There  is  virtually  no  published  documentation  on  the 
subject.  Documentation  is  based  almost  entirely  on 
documentary  evidence  (primary  sources)  and  for  the  most  part 
includes  firsthand  accounts  reported  in  lessons  learned 
reports,  after  action  reports,  and  interviews. 


7 


Consider  first  the  limitations  of  lessons  learned 
reports.  Understandably,  most  of  the  lessons  learned 
reports  are  problematic  in  nature  and  not  always 
constructive.  Those  who  reported  the  lessons  learned  did  not 
always  understand  that  many  of  the  problems  they  described 
were  really  symptomatic  of  larger  problems  beyond  their  level 
of  operation/involvement.  Those  who  submitted  lessons 
learned  reports  may  not  have  understood  the  big  picture  of 
personnel  automation  and  where  their  operation/involvement 
fit  into  the  overall  scheme. 

The  limitations  of  after  action  reports  are  more 
apparent.  After  action  reports  are  more  accomplishment 
oriented,  often  de-emphasizing  problems  with  the  focus 
on  the  successes  of  the  operation.  It  is  sometimes  difficult 
to  glean  serious  problems  from  after  action  reports.  After 
all,  few  people  or  organizations  are  likely  to  report  their 
problems,  especially  if  they  resulted  from  their  own  mistakes 
or  oversights. 

Finally,  consider  the  limitations  of  interviews. 

Like  after  action  reports,  with  interviews  there  is  a  risk  of 
people  describing  their  experiences  in  ways  that  protect 
themselves  or  the  organizations  they  were  part  of.  There  may 
also  be  a  problem  with  hidden  agendas  which  could  overshadow 
efforts  to  ascertain  what  actually  occurred. 
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In  spite  of  these  limitations,  lessons  learned 


reports,  after  action  reports,  and  interviews  together  make 
excellent  primary  resources,  particularly  when  they 
substantiate  the  same  findings,  because  of  their  compensating 
value.  The  limitations  of  one  type  of  primary  scource  is 
compenstated  by  the  strengths  of  another.  Chapter  2, 
Literature  Review,  explains,  in  detail,  the  value  of  each  of 
the  primary  sources. 


Delimitations 

The  thesis  covers  a  period  from  August  1990  through 
August  1991.  This  includes  the  mobilization,  deployment, 
sustainment,  and  redeployment  phases  of  the  Persian  Gulf  War. 
This  time  period  includes  Operation  DESERT  STORM  (the  armed 
conflict)  as  well  as  those  operations  immediately  before  and 
after.  However,  to  impose  constraints  on  the  scope  of  the 
study  so  as  to  make  the  research  feasible,  the  primary  focus 
of  the  thesis  is  the  time  frame  of  Operation  DESERT  STORM. 
There  is  some  comment  on  what  occurred  before  and,  to  a 
smaller  degree,  on  what  occured  immediately  after,  only 
because  they  shed  light  on  the  problems  that  the  personnel 
community  encountered  during  the  actual  war. 

A  second  time  delimitation  imposed  on  the  thesis  is 
related  to  the  research  material  itself.  Often,  with  time, 
people's  perspectives  change  and  become  more  biased. 
Consequently,  the  evidence  used  is  largely  fresh,  firsthand 
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accounts  and  observations.  All  research  material  was 
created  within  one  year  after  the  ending  date  (Aug  1991)  of 
the  deployment.  In  fact,  most  of  the  research  material  was 
developed  within  just  a  few  months  of  the  operation. 

Significance  of  Thesis 

The  significance  or  importance  of  this  thesis  is  that 
it  serves  as  a  mechanism  for  identifying  those  major 
personnel  automation  problems  which  the  personnel  community 
must  address.  In  some  cases  the  solution  may  be  just  a 
matter  of  not  repeating  the  same  policy  decisions  in  other 
circumstances.  While  in  other  instances  the  solution  may 
require  major  system  changes  or  perhaps  even  a  complete 
redesign  of  the  current  system.  Whatever  the  remedy,  the 
findings  of  this  thesis  may  provide  a  basis  for  enhancing  the 
current  automated  personnel  systems  or  for  influencing  the 
development  of  future  systems.  Although  problems  with 
personnel  automation  during  the  war  could  not  be  avoided, 
ignoring  those  problems  and  doing  nothing  to  solve  them 
must  be  avoided.  The  personnel  community  needs  to  learn  from 
its  mistakes  and  become  better  prepared  for  the  next  war. 

This  thesis  helps  begin  that  process. 
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CHAPTER  1 


ENDNOTES 


^"Forces  Committed,"  Military  Review  Vol.  LXXI-9 
(September  1991),  81. 

^John  J.  Yeosock,  Lieutenant  General,  US  Army,  “Army 
Operations  in  the  Gulf  Theater,"  Military  Review  Vol.  LXXI-9 
(September  1991),  3. 

^US  Army  Concepts  Analysis  Agency,  ODCSOPS,  HQDA,  HQDA 
DESERT  SHIELD/DESERT  STORM  After  Action  Report  XHl  Vol.  II, 
Main  Report  (Washington,  DC:  Department  of  the  Army, 
September  1991),  DAPE-1. 
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CHAPTER  2 


LITERATURE  REVIEW 

This  chapter  establishes  a  framework  for 
understanding  the  documentation  which  supports  the  thesis. 

A  general  assessment  of  the  literature  is  provided  and, 
finally,  this  chapter  establishes  the  place  of  the  thesis 
itself  in  the  literature. 

Secondary  Source  Material 

There  has  been  little  research  material  published  on 
personnel  automation  during  Operation  DESERT  STORM.  As  it  is 
still  very  early  after  the  war,  there  are  only  a  few  magazine 
articles  that  focus  exclusively  on  personnel  automation. 

The  Center  for  Army  Lessons  Learned  (CALL),  at  Fort 
Leavenworth,  did  produce  their  final  report  concerning  the 
war.  However,  their  findings  are  classified  and  consequently 
the  thesis  could  not  refer  to  them.  The  CALL  report  only 
addresses  personnel  automation  briefly.  The  many 
unclassified  primary  sources  contributed  to  the  findings  of 
the  CALL  report  and  support  many  other  findings,  but  in  much 
greater  detail.  Even  with  limited  secondary  sources,  there 
is  substantial  unpublished,  primary  source  documentation 
available.  This  material  forms  the  basis  of  the  research  for 


this  thesis. 
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Primary  Source  Material 


An  important  source  for  research  material  to  support 
this  thesis  was  the  Army  Lessons  Learned  System  (ALLS).  CALL 
is  the  Army's  controlling  agency  or  focal  point  for  ALLS. 

The  purpose  of  the  system  is  to  provide  a  mechanism  for 
collection  of  Army  lessons-learned  from  battalion  through 
echelons  above  corps,  to  the  Total  Army.^  The  system 
provides  a  nonthreatening  means  for  Army  employees  to 
identify  useful  lessons.  A  researcher  cannot  identify  either 
the  individual  submitting  the  observation  or  the 
unit/organization  from  which  he/she  originates.  Researchers 
must  preserve  this  right  to  anonymity  or  they  will  not 
receive  access  to  the  research  material. 

The  format  of  the  lessons  learned  is  standard  and 
compatible  with  the  Joint  After  Action  Reporting  System 
(JAARS)  format.^  Army  units/staffs  submit  lessons  learned 
which  impact  other  military  services  (Navy,  Air  Force,  etc.) 
into  JAARS.  CALL  has  over  6,700  Army  lessons  learned  related 
to  Operation  DESERT  STORM  on  a  database.  Of  these  lessons, 
over  100  deal  directly  with  personnel  automation. 

CALL  is  the  source  of  another  valuable  type  of 
research  material  -  unit  after  action  reports.  CALL  serves 
as  the  Army's  repository  for  all  after  action  reports  from 
Operation  DESERT  STORM.  Units,  major  commands  (MACOMS), 
agencies,  and  elements  of  Headquarters,  Department  of  the 
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Array  (HQDA),  have  all  provided  CALL  with  copies  of  their 
reports.  CALL  has  hundreds  of  volumes  available  in  various 
formats.  Not  all  of  them  address  personnel  automation  during 
Operation  DESERT  STORM.  Many  of  them  do.  The  after  action 
reports  from  the  United  States  Total  Army  Personnel  Command 
(PERSCOM),  10th  PERSCOM,  1st  PERSCOM,  Personnel  Groups,  and 
from  Gls/AGs/Sls  were  of  particular  value  to  this  thesis. 

Research  material  for  the  thesis  also  included 
documentation  from  the  Mobilization  Automation  Task.  Force. 
This  body  was  formed  by  the  Office  of  the  Deputy  Chief  of 
Staff  for  Personnel  (ODCSPER)  at  Headquarters,  Department  of 
the  Array  (HQDA),  to  study  personnel  automation  in  support  of 
the  war  and  make  recommendations.  The  task  force  included 
many  of  those  who  were  directly  involved  in  personnel 
automation  support  during  Operation  DESERT  STORM.  According 
to  the  task  force  report,  the  personnel  automation  issues 
were  the  most  significant  shortcomings  in  mobilization  in 
support  of  Operation  DESERT  STORM.  Although  the  focus  of  the 
task  force's  efforts  was  on  mobilization  and  demobilization, 
they  also  addressed  sustainment  problems.  The  task  force, 
for  the  most  part,  identified  general  problems,  laid  out 
broad  requirements  and  tasks,  and  provided  justification  for 
the  continued  funding  of  future  personnel  automated  systems. 

Other  documentation  used  as  research  material 
included  briefing  slides  and  working  papers.  In  some  cases. 
Government  offices  provided  copies  of  the  file  records  and 
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briefing  slides  they  used  at  the  time  of  Operation  DESERT 
STORM.  Some  of  the  slides  were  especially  helpful  in 
graphically  portraying  personnel  automation  doctrine  and 
actual  practice  during  the  operation. 

Interviews  were  another  valuable  research  resource 
for  the  thesis.  These  interviews  were  with  Government 
employees  who  worked  with  personnel  automation  during 
Operation  DESERT  STORM.  They  included  individuals  from  each 
level  of  operation  (brigade,  division,  corps,  theater 
PERSCOM,  HQDA  PERSCOM,  HQDA  ODCSPER) .  Those  interviewed 
provided  a  unique  perspective  into  the  problems  encountered 
which  was  not  always  apparent  in  the  hard  copy  documentation. 

General  Assessment  of  Research  Material 

Overall,  the  research  material  is  representative  of 
the  Total  Army.  Each  echelon  identified  the  major  problems 
addressed  in  this  thesis  through  every  type  of  research 
material  used  to  support  the  thesis. 

Most  significantly.  Army  units/staffs  made  their 
observations  immediately  after  the  war  while  memories  were 
still  fresh  and  largely  unbiased.  In  most  cases, 
units/staffs  produced  their  reports  and  quickly  provided 
them  to  researchers  within  a  few  months  after  the  war. 
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Role  of  the  Thesis  in  Literature 

This  thesis  plays  an  important  role  as  part  of  the 
literature  on  the  topic.  It  ties  together  observations  from 
the  tactical  level  to  the  top  of  the  personnel  system.  It 
also  provides  an  objective  analysis  of  the  available  research 
material.  Finally,  this  thesis  is  important  to  the 
literature  on  the  subject  because  it  constitutes  the  first 
major  attempt  at  synthesis.  It  provides  to  future 
researchers  a  comprehensive  study  of  the  major  shortfalls 
encountered  with  personnel  automation  during  the  Gulf  War. 

Chapter  2  Conclusions 

Understanding  the  nature  of  the  literature  which 
supports  this  thesis  is  important.  This  thesis  is  based  on 
original  research  largely  from  firsthand  accounts.  As  this 
thesis  is  one  of  the  first  secondary  sources  on  the  topic,  it 
has  an  important  place  in  the  literature.  Just  as  it  is 
important  to  understand  the  nature  of  the  research  material, 
it  is  essential  to  understand  the  research  methodology  which 
is  described  in  the  next  chapter. 
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CHAPTER  2 


ENDNOTES 


^US  Army,  ^  11-33 ,  Army  Lessons  Learned  Program:  System 
Deyelopment  and  Application  (Washington,  DC:  Department  of 
the  Army,  1989),  3. 

11-33  (1989),  7. 

^US  Army,  Office  of  the  Deputy  Chief  of  Staff  for 
Personnel  (ODCSPER),  ODCSPER  Mobilization  Automation  Task 
Force  -  Action  Plan  (Washington,  DC:  Department  of  the  Army, 
1991),  1-24. 
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CHAPTER  3 


RESEARCH  METHODOLOGY 

The  purpose  of  this  chapter  is  to  describe  the 
methodology  used  to  conduct  the  research  and  write  this 
thesis.  There  were  four  phases  to  the  research  methodology. 
They  were  a  collection  phase,  an  organization  phase,  an 
analysis  phase,  and  an  interpretation  phase.  Each  of  these 
phases  are  explained  in  detail  in  this  chapter. 

Collection  Phase 

This  phase  of  the  methodology  reguired  the  gathering 
of  the  research  materials  for  the  thesis.  The  materials 
generally  collected  dealt  with  one  of  the  following  areas  of 
interest:  documentation  concerning  personnel  automation 
doctrine  at  the  time  of  Operation  DESERT  STORM;  documentation 
describing  how  personnel  automation  actually  operated  during 
Operation  DESERT  STORM;  and  to  some  degree,  documentation  of 
the  problems  or  impacts  that  the  personnel  community 
encountered  from  noncorapliance  with  doctrine  (either  because 
the  personnel  community  ignored  the  doctrine  and  just  did  not 
follow  it,  or  because  the  doctrine  was  broken  and  they  could 
not  implement  it  if  they  wanted  to). 
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To  be  useful,  the  research  material  needed  to  conform 
with  several  criteria.  Documentation  had  to  come  from 
official  Government  sources.  Lessons  learned  reports  and 
after  action  reports  had  to  document  firsthand  observations. 
Interviews  had  to  be  with  individuals  who  had  firsthand 
knowledge  of  the  topic.  Interviews  were  especially  useful 
because  they  provided  a  means  to  clarify  documentation  and 
validate  findings. 


Organization  Phase 

The  organization  phase  involved  organizing  the 
collected  information  into  groupings  or  categories.  The 
first  category  concerned  personnel  automation  doctrine  and 
policies  at  the  time  of  Operation  DESERT  STORM.  The  second 
category  dealt  with  how  the  personnel  community  actually 
performed  personnel  automation  during  the  operation. 

Finally,  the  last  category  had  to  do  with  the  consequences  or 
problems  resulting  from  the  conflict  between  the  first  two 
categories . 

After  completing  all  phases  of  the  methodology,  the 
findings  concerning  these  categories  evolved  into  Chapters  4, 
5  and  6  of  the  thesis.  Each  of  these  three  categories  lent 
themselves  to  further  subdivision  into  the  component  parts  of 
personnel  automation  which  include:  functionality,  software, 
interfaces,  hardware,  and  communications.  These  subdivisions 
became  the  sections  within  chapters  4,  5,  and  6  of  the 


thesis . 
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Analysis  Phase 


This  phase  of  the  research  methodology  initially 
required  assessing  the  value  of  the  organized  information 
and  making  decisions  about  what  material  was  appropriate  for 
use  in  the  thesis  and  what  was  not.  This  phase  also  required 
an  actual  comparison  between  the  way  the  doctrine  and 
policies  intended  personnel  automation  to  function  and  how  it 
actually  did  function  during  the  operation. 

Interpretation  Phase 

This  phase  of  the  research  methodology  required 
formulating  the  thesis  findings.  To  avoid  the  possibility  of 
misinterpretation,  these  findings  required  validation  through 
interviews.  The  people  interviewed  were  not  only  able  to 
clarify  problems  and  circumstances  but  they  were  able  to 
verify  the  findings  as  accurate.  Of  course,  with  confirmed 
findings  in  hand,  the  writing  of  the  thesis  followed. 

The  next  three  chapters  are  the  product  of  the  research 
methodology. 


Chapter  3  Conclusions 

Understanding  the  research  methodology  is  important. 
One  of  the  significant  steps  in  the  research  methodology  for 
this  thesis  was  the  validation  of  all  findings  by  interviews 
with  people  who  participated  in  Operation  DESERT  STORM. 
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Although  the  research  methodology  was  simplistic,  the  end 
result  was  findings  based  on  thorough,  substantiated 
research. 
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CHAPTER  4 


PERSONNEL  AUTOMATION  DOCTRINE 

This  chapter  describes  personnel  automation  doctrine 
as  it  existed  at  the  time  of  Operation  DESERT  STORM.  The 
intent  of  this  chapter  is  to  describe  the  doctrinal  system  in 
isolation  from  what  really  happened  (Chapter  5  addresses 
execution).  Wartime  doctrine  requires:  streamlined 
procedures  and  policies,  SIDPERS-Wartime  and  C2SRS  software, 
interfaces  between  SIDPERS  and  other  automated  systems, 
interfaces  between  personnel  functional  areas,  TACCS  hardware 
at  tactical  units,  CTASC  II  hardware  at  echelons  above 
division,  and  communications  between  echelons.  This  chapter 
explains  automation  doctrine  in  support  of  personnel 
accounting,  and  strength  reporting,  using  the  components  of 
personnel  automation  (functionality,  software,  interfaces, 
hardware,  communications). 

There  is  no  single  source  for  doctrine  addressing 
personnel  automation.  Some  of  the  sources  include:  Army 
publications;  regulations,  field  manuals,  training  circulars, 
etc.;  Department  of  the  Army  policies  and  interface 
agreements;  software  functional  descriptions/specifications, 
and  automation  architecture  plans.  FM  12-6  Personnel 
Doctrine.  FM  100-10  Combat  Service  Support  and  ^  600-8 , 
Military  Personnel  Management  are  the  primary  sources  of  much 
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of  the  doctrine  explained  in  this  chapter.  The  Field  Systems 
Directorate  of  the  Total  Army  Personnel  Command  (PERSCOM) 
provided  much  of  the  other  doctrinal  information  not 
addressed  in  these  publications. 

Functionality 

At  the  time  of  Operation  DESERT  STORM,  doctrine 
prescribed  that  when  units  go  to  war  they  operate  in  a 
wartime  mode,  performing  only  those  military  personnel 
functions  critical  to  success  on  the  battlefield.  Doctrine 
never  intended  for  units  to  maintain  all  of  the  many 
peacetime  functions  in  wartime. 

The  primary  role  of  the  personnel  system  [during 
wartime]  can  be  best  summarized  as  managing  combat- 
essential  information  to  support  the  decision  making 
process  and  delivering  replacements,  mail,  and  other 
personnel  services.^ 

The  critical  military  personnel  functions  on  the 
battlefield  include:  replacement  operations,  strength 
management,  personnel  database  management,  personnel 
information  management,  and  personnel  accounting  and  strength 
reporting  which  also  affects  casualty  and  postal  operations 
(see  figure  4-1,  page  24).  Other  military  personnel 
functions  are  either  nonessential  or  not  performed  at  all  on 
the  battlefield,  examples  include;  career  planning,  retiree 
support,  recruiting,  retention,  transition  processing,  and 
many  types  of  soldier  applications. 
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Figure  4-1 


Accounting  for  individual  soldiers,  and  unit  strength 
reporting  on  the  battlefield,  are  critical  functions  for 
units  and  personnel  elements  at  all  echelons.  The 
information  generated  from  personnel  accounting  and  strength 
reporting  supports  the  battlefield  commander  and  the  tactical 
decision  making  process.  This  information  enables  the 
commander  to  determine  his  personnel  capabilities  for  battle. 
Those  units  with  acceptable  strength  levels  (determined  by 
the  commander)  are  operationally  effective  to  be  committed  in 
battle.  Those  that  are  not  operationally  effective,  bjcause 
of  shortages  of  key  personnel,  may  not  be  committed  in  battle 
or  they  may  be  relegated  to  a  secondary  or  supporting  role.'^ 
The  doctrine  concerning  personnel  accounting  and  strength 


24 


reporting  existent  at  the  time  of  Operation  DESERT  STORM  is 
explained  below. 

Units  accomplish  personnel  accounting  and  strength 
reporting  through  both  hasty  and  deliberate  means.  Units 
produce  hasty  reports  manually  to  support  the  decisions 
required  by  the  current  battle.  Units  also  submit 
transactions  to  update  the  personnel  database  (SIDPERS- 
Wartime)  to  ensure  continuing  accuracy.  From  this  database, 
automation  clerks  then  produce  deliberate  reports  to  support 
personnel  management  decisions  such  as  assignment  and 
crossleveling  decisions. 

Although  units  produce  hasty  reports  manually, 
they  may  also  produce  the  same  reports  with  tactical 
automation  capabilities.  The  section  entitled:  Hardware 
describes  these  capabilities.  Figure  4-2,  on  page  26,  shows 
a  sample  of  the  hasty  report.  Figures  4-6  and  4-7  show 
samples  of  the  same  information  but  in  automated  formats 
produced  from  tactical  automation  equipment.  The  section  of 
the  chapter  entitled:  Software  describes  these  automated 
samples  on  pages  35  and  36. 

Strength  managers  at  every  echelon  must  reconcile 
hasty  and  deliberate  information  on  a  daily  basis.  This 
involves  matching  the  two  types  of  reports  and  resolving  the 
differences.^ 
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Figure  4-2 


Data  flows  within  a  division  through  both  personnel 
channels  and  conunand  channels.  The  manual,  hasty  reports  and 
the  same  reports  produced  on  tactical  automation  equipment 
pass  through  command  channels  (unit  commanders  -  battalion  SI 

-  brigade  SI  -  division  Gl/AG  -  Corps  AG) .  Deliberate 
SIDPERS-Wartime  reporting  passes  through  personnel  channels 
(unit  clerks  -  battalion  personnel  and  administration  center 

-  personnel  service  company  -  personnel  group) . 
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Units  accomplish  deliberate  SIDPERS-Wartime  reporting 
through  personnel  channels.  Units  provide  the  necessary 
information  for  the  battalion  Sl/PAC  to  prepare  the 
transactions.  The  battalion  Sl/PAC  then  provides  the 
transactions  to  the  personnel  service  company  (PSC)  which 
services  the  battalion.  Clerks  at  the  PSC  integrate  the 
information/transactions  into  the  SIDPERS-Wartime  database. 
PSC  clerks  then  further  process  the  data  through  the 
personnel  group  to  the  theater  PERSCOM  and  ultimately  back  to 
the  Total  Army  PERSCOM.^ 

Units  accomplish  hasty  reporting  through  command 
channels.  Unit  Commanders  first  annotate  changes  to  their 
unit  strengths  on  their  battle  rosters.  When  the  battalion 
SI  receives  this  information,  he  creates  hasty  reports.  The 
battnlion  SI  also  provides  a  copy  of  the  hasty  reports  to  the 
PAC.  The  PAC  generates  the  same  reports  on  their  tactical 
automation  hardware  using  the  Command  Control  Strength 
Reporting  System  (C2SRS  -  described  in  greater  detailed  in 
the  section  entitled:  Software).  Both  the  hasty  reports  and 
the  C2SRS  reports  then  flow  to  the  brigade  main  command  post 
(CP).  The  brigade  SI  uses  the  reports  to  manage  the 
brigade's  personnel  assets  and  influence  planning.  The 
brigade  main  CP  forwards  the  hasty  and  C2SRS  reports  to  the 
division  main  CP  to  influence  planning  and  decision  making  at 
that  level.  The  division  main  CP  sends  the  hasty  and  C2SRS 
reports  to  the  division  Gl/AG  rear  and  to  the  division 
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tactical  command  post  (DTAC).  The  DTAC  uses  the  information 
to  fight  the  current  battle  and  the  AG/Gl  uses  it  to  manage 
the  division  strength.  The  division  AG/Gl  rear  forwards  the 
hasty  and  C2SRS  reports  to  the  corps  AG.^ 

From  the  corps  level  the  hasty  and  C2SRS  reports  then 
flow  through  personnel  channels.  The  corps  AG  receives  the 
hasty  and  C2SRS  reports  from  the  division  AG/Gl  rear.  The 
staffing  of  the  corps  AG  comes  principally  from  the 
personnel  group  as  the  corps  AG  is  also  the  group  commander. 
Personnel  group  clerks  use  the  reports  for  strength/personnel 
management  purposes .  The  personnel  group  provides  the  hasty 
and  C2SRS  information  to  the  corps  main  CP  to  provide  the 
corps  G1  and  commander  with  the  information  needed  to  fight 
the  battle  and  make  plans  as  needed.  The  personnel  group 
also  forwards  the  hasty  and  C2SRS  reports  to  the  theater 
PERSCOM  where  they  use  the  reports  for  strength  management 
purposes  and  for  replacement  decisions.  The  theater  PERSCOM 
provides  the  hasty  and  C2SRS  information  to  the  theater  Army 
CP  to  assist  in  battlefield  planning.  The  theater  PERSCOM 
also  provides  the  information  to  Total  Army  PERSCOM  which 
constitutes  the  requisitions  for  the  theater.® 

Figure  4-3,  on  page  29,  illustrates  the  personnel 
accounting  and  strength  reporting  data  flow  for  divisional 
units . 
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Figure  4-3 


Figure  4-4,  on  page  30,  shows  the  personnel  and 
strength  reporting  data  flow  for  nondivisional  units  and 
separate  battalions.  The  data  flow  is  similar  to  the  data 
flow  for  divisional  units,  however,  non  divisional  units 
report  directly  to  the  corps  AG  or  personnel  group  and  only 
provide  informational  copies  of  their  hasty  reports  to  the 
division  they  support.  Separate  battalions  of  a  division  do 
not  have  brigades  to  report  through  and  consequently,  they 
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provide  their  hasty  and  C2SRS  reports  directly  to  the 
division  Gl/AG  rear. 


Figure  4-4 


Wartime  doctrine  concerning  personnel  accounting  and 
strength  reporting,  as  it  existed  at  the  time  of  Operation 
DESERT  STORM,  was  not  complete.  It  did  not  address  the  data 
flow  for  units  at  echelons  above  corps,  within  the 
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communications  zone  (COMMZ).  Nor  did  doctrine  explain  how 
the  flow  of  data  should  transition  from  an  immature  theater, 
with  few  personnel  elements/units  deployed,  to  a  mature 
theater,  with  the  full  deployment  of  personnel  elements/units 
to  include  a  theater  PERSCOM. 

At  the  time  of  Operation  DESERT  STORM,  wartime 
doctrine,  regarding  automation  as  it  supports  personnel 
accounting  and  strength  reporting,  reguired  the  maintenance 
and  tracking  of  "combat  essential  information. “  Doctrine  did 
not  reguire  the  maintenance  of  all  the  data  which  supports 
the  many  peacetime  personnel  functions.^ 

Doctrine  also  intended  that  personnel  automation 
during  war  allow  for  "wartime  required"  strength  accounting 
as  opposed  to  "peacetime  authorized"  strength  accounting.® 
Required  strength  accounting  allows  personnel  managers  to 
maintain  and  manage  units  at  the  manning  levels  considered 
necessary  for  those  units  to  perform  their  wartime  missions. 
Authorized  strength  accounting  allows  personnel  managers  to 
maintain  and  manage  units  at  peacetime  strength  levels 
(generally  lower  than  their  wartime  strength  levels). 

The  latter,  over  the  years,  has  also  been  a  system  for 
allocating  shortages  as  much  as  for  filling  units. 

Doctrine  at  the  time  of  Operation  DESERT  STORM  did 
not  provide  for  a  system  that  would  allow  for  maintenance  of 
both  required  and  authorized  strength  accounting  as  the 
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scenario  escalated  from  deference  or  limited  combat  activity 
to  a  medium  or  high  intensity  conflict.  The  doctrine 
provided  for  only  one  of  the  two  systems,  either  for 
peacetime  or  wartime  processing. 

Wartime  personnel  doctrine  at  the  time  of  Operation 
DESERT  STORM  also  provided  for  the  practice  of  using  task 
organization.  A  task  organization  is  the  temporary 
realignment  of  units  usually  for  tactical  purposes.  During 
battle,  task  organizing  is  common,  especially  among  combat 
units.  Task  organizing  impacts  a  unit’s  command 
relationships,  and  it  impacts  upon  the  unit’s  reporting 
procedures.  Usually,  there  is  an  expectation  that  the 
original  command  alignment  is  re-established  at  some  point  in 
the  future.^ 

A  basic  assumption  underpinning  personnel  doctrine 
at  the  time  of  Operation  DESERT  STORM  was  that,  during 
wartime  the  required  personnel  force  structure  would  be 
present  in  the  field  in  the  strength  necessary  to  support  the 
force.  The  general  expectation  was  that  the  personnel  force 
structure  would  be  built  up  gradually,  as  more  and  more  units 
deploy.  Doctrine  did  not  prov’-'e  for  a  scenario  where  the 
Army  deploys  the  personnel  force  structure  long  after  the 
rest  of  the  force  is  on  the  ground. 

At  the  time  of  Operation  DESERT  STORM,  there 
existed  three  separate  and  distinctly  different  field  systems 
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for  the  three  Army  components,  the  Active  Army  (AC),  the  Army 
National  Guard  (ARNG) ,  and  the  United  States  Army  Reserve 
(USAR).  The  Active  Army  maintained  SIDPERS  in  peacetime  and 
SIDPERS-Wartime  during  war.  The  Army  National  Guard 
maintained  SIDPERS-ARNG.  And  the  Uniced  States  Army  Reserve 
maintained  SIDPERS-USAR.  These  three  automated  systems  were 
largely  noncompatable  and  supported  only  the  unique 
functionality  of  the  components  for  which  they  were  designed. 

Software 


The  personnel  software  intended  for  use  during  war 
included  SIDPERS-Wartime  and  the  Command  and  Control  Strength 
Reporting  System  (C2SRS).  The  personnel  community  designed 
both  of  these  systems  to  make  personnel  accounting  and 
strength  reporting  more  streamlined  during  war. 

Consequently,  both  of  these  software  systems  focused  on 
providing  only  the  critical  information  needed  to  support 
battlefield  commanders  and  personnel  managers. 

The  personnel  community  designed  SIDPERS-Wartime  for 
the  purpose  of  accounting  for  the  force  based  on  required 
strengths.  The  true  benefit  of  the  software  is  that  it 
cuts  down  significantly  the  number  of  transactions  needed  to 
maintain  the  personnel  database.  Even  though  there  are 
considerably  fewer  data  elements  to  keep  updated,  there  are 
sufficient  data  elements  to  produce  the  needed  deliberate 
wartime  personnel  management  reports. 
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C2SRS  is  TACCS  based  software  and  a  subset  of 
SIDPERS.  Doctrine  prescribed  that  it  be  at  battalion, 
brigade  and  division  levels.  The  software's  principal 
reports/products  include  an  automated  battle  roster,  an 
automated  personnel  summary,  an  automated  personnel 
requirements  report,  and  a  task  force  personnel  summary. 


The  battle  roster  is  the  C2SRS'  principal  personnel 
accounting  document.  The  battle  roster  is  the  main  source  of 
data  for  generating  the  other  C2SRS  reports.  The  key  element 
of  the  battle  roster  is  the  soldier’s  actual  duty  status 
(present  for  duty  -  PDY,  missing  in  action  -  MIA,  etc.). 
Figure  4-5  shows  a  sample  of  the  C2SRS  battle  roster  report 
below. 
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The  personnel  suminary  is  a  strength  reporting 
document.  It  reports  the  aggregate  totals  of  the  units 
current  operating  strength  by  officer,  warrant  officer  and 
enlisted  personnel.  Doctrine  intended  for  clerks  to 
generate  this  report  both  manually  and  by  using  C2SRS. 

The  personnel  summary  shows  the  gains,  losses  and  duty  status 
changes  from  the  last  report.  Figure  4-6  shows  the  automated 
personnel  summary  below. 
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Figure  4-6 

The  personnel  requirements  report  is  a  strength 


reporting  product  that  shows  the  unit's  personnel 
requirements  by  rank  and  skill  or  specialty.  These 
requirements  constitute  the  units  requisitions  for  personnel 


replacements.  Clerks  produce  this  report  both  manually  and 
by  using  the  C2SRS  software.  Figure  4-7  shows  a  sample  of 
the  C2SRS  report  below. 


Figure  4-7 


The  task  force  personnel  summary  is  a  strength 
reporting  document  only  available  for  use  within  C2SRS. 
Doctrine  at  the  time  of  Operation  DESERT  STORM  did  not 
require  units  to  produce  it  by  hand  as  a  hasty  report. 

The  task  force  personnel  summary  is  comparable  to  the 
personnel  summary  except  that  it  shows  the  personnel  status 
for  task  forces.  The  personnel  database  does  not  generate 
the  report,  rather,  clerks  must  key  in  all  of  the  data  into 
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the  C2SRS  software.  The  data  from  this  report  does  not 
update  any  database  whether  that  be  the  database  which 
directly  supports  the  C2SRS  software  or  the  S I DPERS -Wartime 
database.  The  report  is  strictly  a  manually  fed  C2SRS 
report  providing  only  minimal  strength  reporting  capability. 

1  O 

Figure  4-8  shows  a  sample  of  this  C2SRS  report  below. 


Figure  4-8 

C2SRS  was  the  product  of  Soldier  Support  Center  and 
Total  Army  PERSCOM.  The  intent  of  the  software  was  to 
provide  units  and  personnel  managers  with  an  easy  to  use, 
menu  driven  software  package  in  support  of  contingency  and 
wartime  personnel  operations. 
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"he  personnel  community  intended  their  automated 
personnel  systems  to  provide  timely  and  responsive  data.  The 
community  also  intended  for  these  systems  to  track  different 
categories  of  personnel  activated  and  deployed.  These 
software  systems  were  also  to  provide  accountability  of 
personnel  through  demobilization. 

Personnel  doctrine  at  the  time  of  Operation  Desert 
Storm  also  prescribed  that  data  be  furnished  from  field  units 
through  personnel  channels  to  the  corps  and  theater  levels. 
Corps  and  theater  personnel  units/elements  would  have  roll-up 
capability  as  well  as  the  ability  to  maintain  their  own  data¬ 
bases.  Doctrine  required  personnel  automation  to  extract 
combat  essential  personnel  information  from  the  command  data¬ 
bases  [unit  databases]  and  provide  consolidated  databases  to 
corps  and  theater-level  strength,  casualty,  and  postal 
managers. From  these  corps/theater  databases,  personnel 
managers  could  produce  their  own  personnel  accounting  and 
strength  reporting  documents  to  support  the  unique 
requirements  of  the  corps  or  theater  commanders  in  making  the 
critical  tactical  and  operational  decisions  of  the 
battlefield. 


Interfaces 

At  the  time  of  Operation  DESERT  STORM,  personnel 
automation  agreements  (between  system  proponents /managers ) 
called  for  an  interface  to  exist  between  the  Mobilization 
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Personnel  System  (MOBPERS)  and  SIDPERS  for  the  purpose  of 
accessioning  reserve  component  soldiers  on  active  duty.^^ 

With  this  interface  in  place,  the  reserve  component  could 
transfer  mobilization  data  from  their  own  automated  systems 
directly  into  SIDPERS.  The  agreement  intended  this  to  occur 
without  extensive  rekeying  of  information. 

The  interface  agreement  between  these  two  systems 
required  MOBPERS  to  provide  to  SIDPERS  only  the  minimum 
essential  data  required  to  allow  accessioning  of  soldiers 
into  the  active  Army.  The  data  included:  name,  grade,  date 
of  rank,  military  personnel  class,  social  security  number, 
sex,  race,  service  component,  specialty/skill  information, 
and  the  gaining  unit  processing  code. 

Personnel  doctrine  also  prescribed  that  interfaces 
exist  for  the  purposes  of  providing  and  exchanging  data  to 
other  major  functional  areas.  Figure  4-9,  on  page  40,  shows 
the  reliance  of  other  personnel  functional  areas  on  personnel 
accounting  and  strength  reporting  for  data.  These  other 
personnel  functional  areas  included:  personnel  information 
management,  personnel  database  management,  replacement 
operations,  casualty  operations,  and  postal  operations. 
Doctrinally,  the  exchange  of  data  from  personnel  accounting 
and  strength  reporting  to  these  other  functional  areas 
needed  to  occur  to  have  efficient  and  effective  personnel 
service  support. 


THE  FLOW  OF  CRITICAL  Rf  RSONNEL  INFORMATION 


I 


Figure  4-9 


Hardware 

Doctrine  prescribed  that  TACCS  boxes  would  be 
located  at  separate  company,  battalion,  brigade,  and  division 
levels.^®  The  TACCS  is  a  portable,  ruggedized  microcomputer 
designed  for  field  use.  The  TACCS  includes  a  central 
processing  unit  with  hard  disk  drive,  a  keyboard,  a  screen, 
and  a  printer.  It  uses  the  standard  5  1/4  inch  floppy  disk. 
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The  dot  matrix  printer  is  durable  and  ideal  for  field  use. 

The  TACCS  is  capable  of  telecommunications  with  both  secure 
and  nonsecure  transmission  of  data  over  FM  radio  and  over 
military  or  commercial  telephone  lines.  Personnel  clerks 
generally  operate  the  equipment. 

TACCS-Enhanced  equipment,  when  fielded,  will 
significantly  upgrade  tactical  automation  capability. 
TACCS-Enhanced  provides  a  substantial  increase  in  memory  with 
a  significant  improvement  in  processing  time.  Prototypes  of 
the  equipment  were  used  during  Operation  DESERT  STORM. 

There  are  drawbacks  to  both  TACCS  and  TACCS-Enhanced 
equipment.  Although  the  TACCS  printer  is  ruggedized  for 
field  use,  it  does  not  produce  the  near  letter  quality  output 
needed  for  the  production  of  orders,  evaluation  reports,  and 
award  certificates.  Furthermore,  neither  hardware  system 
allows  for  use  of  standard  commercial  parallel  and  serial 
printers  which  could  provide  the  near  letter  quality.  Also, 
neither  system  is  expandable  to  accommodate  the  addition  of 
external  tape,  hard,  or  CD-ROM  drivers.  Because  of  the 
availability  of  MS-DOS  compatible  laptop  computers  in  recent 
years,  TACCS  users  have  complained  of  the  size  and  expense  of 
TACCS  equipment  (approximately  $18,000).  After  all,  TACCS  or 
TACCS-Enhanced  equipment  does  not  fit  in  a  ruck  sack  (it  is 
carried  in  three  containers  requiring  two  people  to  carry 

1  n 

each  container)  and  it  is  expensive  to  replace. 
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At  the  time  of  Operation  DESERT  STORM,  doctrine 

prescribed  for  the  Corps  Theater  ADP  Service  Center  II 

(CTASC  II)  to  be  at  corps  and  theater  levels.  The  CTASC  II 

is  a  mobile  ADP  system  which  provides  computer  support  to  CSS 

units  in  the  corps  and  echelons  above  corps  assigned  to 

logistical,  medical,  personnel,  and  financial  missions. 

Currently,  it  is  a  mini-computer  housed  in  three  integrated, 

light  weight  shelters  mounted  on  three  Commercial  Utility 

Cargo  Vehicles  (CUCV).  A  standard  integrated  command  post 

(CP)  tent  is  also  provided  to  be  used  outside  for  additional 

work  space. SIDPERS  has  never  been  adapted  to  work  on  this 
1  Q 

equipment . 

An  alternative  to  the  CTASC  II  is  the  CTASC  I. 
Although  doctrine  did  not  prescribe  for  its  use,  SIDPERS 
could  be  processed  on  it.^®  The  CTASC  I  is  a  self  contained 
main  frame  computer.  It  is  housed  in  expandable  vans  with 
its  own  power  generating  capability.  Forty  personnel  run  and 
maintain  this  system.  Operators  are  automation  specialists 
with  extensive  computer  training.  See  Figure  4-10,  on  page 
43,  for  the  basic  pictoral  concept  of  a  CTASC  system. 

At  the  time  of  Operation  DESERT  STORM,  the  personnel 
community  fully  intended  that  all  units  deployed  with 
hardware  be  trained  on  how  to  use  their  systems .  The 
community  further  expected  that  the  reserve  units  which 
were  issued  TACCS  boxes  prior  to  Operation  DESERT  STORM  be 
totally  proficient  in  using  this  hardware.  This  would 
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have  required  those  reserve  units  to  conduct  sustainment 
training  regularly  after  the  new  equipment  training  which 
they  received  at  the  time  of  system  fielding. 


Corps  Theater  AOP  Service  Center 
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Figure  4-10 


Communications 


Doctrine  provided  for  communications  capability  to 
exist  between  echelons  for  the  purpose  of  electronically 
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transmitting  data  ultimately  to  DA  PERSCOM  back  in  the 
United  States  or  Europe.  Battalions,  brigades,  and  divisions 
were  supposed  to  be  able  to  transmit  their  data  cnrough  TACCS 
over  wire  or  FM  radio.  The  worse  case  would  require  them  to 
hand  carry  floppy  disks  to  the  corps  level. rhe  corps  was 
also  supposed  to  be  able  to  transmit  data  to  the  theater 
PERSCOM  over  wire  or  FM  radio.  Lastly,  the  theater  PERSCOM 
was  supposed  to  be  able  to  transmit  data  directly  to  Total 
Army  PERSCOM  by  way  of  DDN  or  AUTODIN.  Figure  4-11  is  an 
illustration  of  this  communication  concept/architecture . 


Figure  4-11 
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Chapter  4  Conclusions 

Doctrine  existed  at  the  time  of  Operation  DESERT 
STORM  for  the  automated  support  of  personnel  accounting  and 
strength  reporting.  This  chapter  describes  that  doctrine. 

In  general  terms,  wartime  doctrine  required:  streamlined 
wartime  policies  and  procedures,  SIDPERS-Wartime  and  C2SRS 
software,  interfaces  between  automated  systems,  interfaces 
between  personnel  functional  areas,  TACCS  equipment  at  the 
tactical  unit  level,  CTASC  II  hardware  at  the  corps  and 
theater  levels,  and  communication  capability  between 
echelons . 

A  fully  implementable  personnel  automation  doctrine 
would  have  benefited  the  personnel  community  during  Operation 
DESERT  STORM.  Although  the  doctrine  seemed  sound  before  the 
war,  the  personnel  community  soon  realized  that  much  of  it 
could  not  be  implemented  during  the  operation.  Instead, 
personnel  units  and  elements  found  they  had  to  improvise  in 
order  to  make  personnel  automation  work,  even  to  accomplish 
the  most  rudimentary  levels  of  strength  reporting  and 
personnel  accountability. 
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CHAPTER  5 


PERSONNEL  AUTOMATION  DURING  OPERATION  DESERT  STORM 

This  chapter  deals  with  the  actual  working/employment 
of  personnel  automation  during  Operation  DESERT  STORM.  The 
personnel  community  found  it  difficult  and  sometimes  even 
impossible  to  implement  existing  personnel  automation 
doctrine.  Consequently,  there  were  often  clear  differences 
between  the  doctrinal  expectations  and  the  way  personnel 
automation  actually  worked  during  the  operation. 

Expectations  of /for  functionality  were  excessive.  Software 
was  untimely,  inflexible,  cumbersome,  and  not  responsive 
enough  to  the  needs  of  the  Total  Army.  Interfaces  were  not 
always  in  place  where  they  should  have  been,  while  existing 
interfaces  did  not  adequately  support  the  automated  personnel 
systems.  Hardware  was  not  fielded  to  all  units  deployed;  nor 
did  all  of  the  units  which  had  hardware  use  it  properly.  And 
finally,  communications  were  largely  lacking  during  much  of 
the  operation.  This  chapter  addresses  each  of  these 
shortfalls  in  greater  detail. 

Functionality 

Personnel  units/eleraents  found  that  they  were  still 
expected  to  support  peacetime  functionality.  This  was  the 
case  even  though  Department  of  the  Army  (DA)  intended  that 
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the  continental  United  States  (CONUS)  sustaining  base  and 
Europe  would  perform  the  peacetime  mission.  There  was  never 
a  transition  to  strictly  wartime  functionality  for  the  units 
deployed  in  Southwest  Asia. 

Because  the  home  stations  were  expected  to  provide 
peacetime  support,  the  deployed  units  did  not  bring  their 
Military  Personnel  Records  Jackets  (MPRJ).  Those  units  which 
anticipated  problems  brought  hasty  personnel  files  with  them 
containing  only  the  critical  information  they  felt  they  would 
need  for  personnel  service  support  in  the  field.  However, 
many  units  did  not  do  this  which  made  the  task  of  providing 
continued  peacetime  support  during  the  war  difficult. 

Two  examples  of  required  support  for  peacetime 
functionality  by  deployed  units  included  retention  processing 
and  peacetime  promotions  (not  to  be  confused  with  wartime, 
battlefield  promotions).  Both  of  these  functional  areas 
depended  heavily  on  using  the  MPRJs  which  were  not  available 
in  the  theater.  Personnel  automation  also  did  not  prove  to 
be  a  reliable  source  of  the  information.  Consequently, 
retention  NCOs  and  promotion  clerks  had  to  coordinate  with 
their  home  stations  to  screen  many  records. 

Units  resorted  to  manual  computations,  often  not 
having  the  required  information  to  make  correct 
assessments  for  accurate  computation  allocations. 

This  was  compounded  by  the  need  to  maintain  all  three 

components'  (Active  Army,  Army  National  Guard,  United 
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States  Army  Reserve)  peacetime  personnel  policies  and 
procedures,  and  not  just  those  of  the  active  Army. 

Because  of  the  expectation  to  maintain  peacetime 
functionality,  automation  clerks  had  to  keep  up  with  the 
myriad  of  personnel  transactions  required  to  sustain  many  of 
the  peacetime  systems.  This  was  still  the  case  even  after 
Headquarters,  Department  of  the  Army  (HQDA)  made  efforts  to 
reduce  the  number  of  transactions  needed  to  be  maintained  by 
the  field.  Clerks  had  to  keep  updated  more  personnel  data 
elements  than  they  would  have  if  they  had  only  to  perform 
wartime  functionality. 

Automated  personnel  accounting  and  strength  reporting 
during  Operation  DESERT  STORM  was  based  on  units ’  peacetime 
authorized  strengths,  as  opposed  to  their  wartime  required 
strengths.  When  actual  hostilities  began  during  Operation 
DESERT  STORM  consideration  was  given  to  begin  managing 
against  required  (versus  authorized)  strength  for 
deployed/deploying  units.  However,  this  proved  impossible 
as  the  automated  personnel  systems  had  not  transitioned  to 
strictly-required-strength-accounting  nor  could  these  systems 
reflect  both  authorizations  and  requirements. 

What  made  matters  worse  was  that  even  the  authoriza¬ 
tion  data  for  the  Reserve  component  was  questionable,  as  far 
as  completeness  and  accuracy. 
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The  automated  interface  between  the  Army’s  system 
managing  structure  and  the  personnel  management 
system  did  not  work  during  DESERT  SHIELD/STORM.  At 
the  installation  level,  for  example,  it  was  necessary 
to  manually  load  more  than  100,000  authorizations 
into  the  active  personnel  system.... 

In  many  cases,  however,  mobilization  stations  did  not  even 

load  the  data  due  to  lack  of  time  and/or  documentation.^ 

During  Operation  DESERT  STORM  automated  personnel 
systems  were  largely  only  able  to  manage  peacetime  command 
alignments  (the  traditional  relationship  of  units  assigned  to 
their  parent  commands).  (For  example,  in  peacetime,  the 
378th  Personnel  Service  Company  (PSC)  is  assigned  to  the  5th 
Personnel  Group.)  The  field  systems,  or  those  systems  main¬ 
tained  at  HQDA,  could  not  recognize  multiple  alignments.^ 

To  continue  the  example,  the  378th  PSC  might  be  attached 
temporarily  to  another  command  during  mobilization,  and, 
after  deployment,  to  yet  another.  After  redeloyment,  the 
378th  PSC  would  likely  be  reassigned  back  to  its  original 
parent  unit,  the  5th  Personnel  Group.  This  temporary 
realignment  of  command  relationships  is  referred  to  as 
task-forcing.  The  Command  and  Control  Strength  Reporting 
System  (C2SRS)  did  provide  limited  task-forcing  capability  to 
the  field.  HQDA  even  upgraded  this  capability  during  the 
operation.^  However,  for  the  most  part,  units  did  not  use  it 
because  of  its  complexity  and  inadequate  design  which  made  it 
unable  to  keep  up  with  the  massive  and  rapidly  changing 

O 

requirements . °  Consequently,  personnel  automated  systems 
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during  the  operation  did  not  provide  adequate  task-forcing 
capability. 


Personnel  systems  and  functionality  were  not 
supported  by  the  timely  deployment  of  personnel  units. 

LTC  Joseph  L.  Revell  from  the  US  Army  Soldier  Support  Center 
deployed  to  Southwest  Asia  with  the  purpose  of  observing 
personnel  operations.  He  explained: 

In  regards  to  Personnel  Management  problems 
within  the  theater,  almost  all  can  be  attributed  to 
two  decisions  and  need  to  be  highlighted.  The  first 
decision  dealt  with  the  lack  of  early  deploying 
personnel  units  in  the  TPFDL  [Time  Phased  Force 
Deployment  List].  The  need  to  project  combat  power 
without  its  supporting  personnel  systems  had  a 
expensive  pricetag  attached  to  it  and  degraded 
significantly  the  functions  of  strength  accounting, 
replacement  operations,  postal  operations,  and 
finally,  casualty  operations.  The  second  decision, 
or  indecision,  was  whether  or  not  this  theater 
required  a  PERSCOM  to  orchestrate  the  personnel 
support  for  the  theater.^ 

Many  deploying  units  were  on  the  ground  for  weeks  before 
their  supporting  personnel  units/eleraents  arrived  to  provide 
their  personnel  support. 


The  theater  PERSCOM  structure  was  not  even  organized 
until  four  months  into  the  deployment.  This  occurred  for  two 
reasons.  First,  it  was  determined  that  AG/personnel  group 
assets  from  the  XVIII  Airborne  Corps  would  provide  the  needed 
support  within  the  theater  of  operations  (at  least  until  a 
second  corps  was  fielded) .  Second,  the  delay  in  organizing  a 
PERSCOM  was  also  consequent  to  the  decision  to  front-load 
combat  elements  for  deterrence  purposes.  Most  of  the  deficit 
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in  structuring  a  balanced  force  existed  at  echelons  above 
corps  for  combat  support  and  combat  survice  support  units . 
There  was  no  effort  made  in  CONUS  to  compensate  for  the  lack 
of  a  PERSCOM  in  theater.  For  example,  a  PERSCOM  could  have 
been  set  up  at  Fort  McPherson.  After  a  second  corps  deployed 
to  Southwest  Asia  (VII  corps  in  November  1990)  the  theater 
PERSCOM  was  organized  (December  1990).  Unfortunately, 
between  November  and  December,  in  the  absence  of  the  theater 
PERSCOM,  the  small  contingent  of  personnel  assets  intially 
deployed  as  part  of  the  XVIII  Airborne  Corps  was  unable  to 
keep  up  with  their  own  expanding  corps  organization,  let 
alone  resolve  theater  level  issues.^®  When  the  theater 
PERSCOM  was  deployed/organized,  it  was  done  in  a  piecemeal 
fashion  over  several  months,  providing  little  direction 
initially . 

During  Operation  DESERT  STORM  there  was  no  single 
integrated  personnel  automated  system.  In  accordance 
with  established  policies  at  the  time,  each  of  the  three 
components  maintained  their  own  distinctly  different  systems. 
Even  though  Congress  has  not  allowed  for  a  single  integrated 
system,  there  is  still  a  need  for  at  least  a  single  source 
database  with  standardized  data  elements. This  database, 
already  anticipated,  is  the  Total  Army  Personnel  database 
(TAPDB).  Ultimately,  TAPDB  will  aggregate  the  three 
component  databases  along  with  the  civilian  personnel  data¬ 
base  into  a  common  source  of  total  Army  personnel 
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information.  Unfortunately,  this  database  is  still 
emerging,  and  was  not  fully  functional  during  the  Operation 
DESERT  STORM.  Figure  5-1,  below  is  a  graphic  representation 
of  TAPDB. 
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Software 

Although  the  Total  Army  PERSCOM  considered  using 
SIDPERS-Wartime  for  deployed  units,  th'^y  made  the  decision  to 
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continue  using  the  peacetime  system,  SIDPERS-2/2 . 75 .  This 
decision  was  based  primarily  on  the  fact  that  the  C2SRS 
software  could  not  work  with  SIDPERS-Wartime .  The  software 
was  only  designed  to  work  on  the  peacetime  system. The 
Total  Army  PERSCOM  further  determined  that  both  CONUS  and 
Europe  home  stations  would  continue  providing  mainframe 
support  to  the  deployed  units.  Maintaining  the  active 
component  peacetime  system  was  especially  difficult  for  the 
activated  reserve  component  units  as  they  lacked 
training,  experience,  and  many  times  the  equipment  necessary 
to  make  the  active  Army  system  work. 


Unfortunately,  SIDPERS-2  and  SIDPERS-2.75  did  not 
provide  the  essential  data  needed  to  manage  the  force  at  all 
echelons,  nor  could  the  software  be  changed  easily. 

SIDPERS-2  was  developed  in  the  early  1970 ’s  as  a 
fixed  length  record/flat  file  system.  Today,  it  is 
old  technology.  To  modify  or  change  it  is  very  labor 
and  time  intensive.  A  simple  change  requires  several 
months  to  modify  programs,  test  them,  and  field  the 
updated  software.^^ 

Operation  DESERT  STORM  just  did  not  provide  the  time  to  make 
all  the  needed  changes.  Consequently,  personnel  managers  at 
all  levels  had  to  devise  and  implement  work-around  solutions. 


Although  C2SRS  was  available,  many  units  improvised 
other  means  to  account  for  personnel  and  provide  strength 
reports.  This  was  especially  true  of  reservists  who  were 
largely  unfamiliar  with  the  software  and  whose  first  exposure 
to  the  software  may  only  have  been  during  mobilization. 
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Units  did  not  always  maintain  their  C2SRS  battle 
rosters.  As  mentioned  in  chapter  4,  the  battle  roster  is  the 
personnel  accounting  tool  key  to  generating  the  C2SRS 
strength  reports.  If  the  battle  rosters  are  not  kept 
current,  then  the  software  cannot  generate  accurate  reports. 
One  division  reported,  “Battle  roster  programs  and  procedures 
were  cumbersome  and  reliability  was  poor."^^  Consequently, 
many  units  did  not  even  bother  maintaining  the  battle  rosters 
or  using  the  C2SRS  software. 

In  the  end,  C2SRS  just  proved  to  be  too  difficult  to 
use.  The  software  was  too  complex.  Soldiers  needed  to  be 
very  familiar  with  the  software  in  order  to  use  it 
effectively.  This  posed  a  problem  for  many  units,  especially 
for  reserve  units.  Active  Army  units  also  lacked  experience 
in  using  the  software  because  they  never  used  it  except 
possibly  during  exercises. 

SIDPERS  and,  generally,  most  of  the  automated 
personnel  systems  which  supported  mobilization  and  HQDA, 
proved  to  be  inadequate  in  providing  timely  and  current 
information.  There  were  many  after  action  reports  by  units 
and  personnel  elements  explaining  that  there  were  extensive 
delays  in  processing  transactions  to  update  SIDPERS  and  other 
personnel  databases.  Just  a  few  examples  are  provided  below 
to  make  the  point  of  how  serious  this  problem  was. 
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(1)  To  begin  with,  reserve  component  units  activated 
with  old  data.  In  fact,  the  mobilization  personnel  data  was 
60  to  90  days  old  by  the  time  SIDPERS  received  it.^^  The 
Mobilization  Personnel  System  (MOBPERS)  was  supposed  to 
preposition  the  acessioning  data.  The  section  entitled. 
Interfaces  describes  MOBPERS  in  greater  detail. 

(2)  SIDPERS  and  other  personnel  automated  systems 
did  not  receive  accurate  organizational  data  until  three 
months  after  Operation  DESERT  SHIELD  began. The  Status  of 
Resources  and  Training  System  (SORTS)  was  the  source  of  this 
data.  Any  follow-on  updating  to  SORTS  also  required 
excessive  time.  One  major  command  reported  that, 

. . .the  time  lag  between  the  date  of  exchange  on 
the  groviid  and  updates  in  the  SORTS  system  was  so 
great  that  SIDPERS  could  not  be  used  effectively  at 
any  level  as  the  basis  for  managing  the  force. 

The  section  entitled.  Interfaces  describes  SORTS  in  greater 

detail . 


(3)  The  processing  of  transactions  to  support 
SIDPERS  was  also  lengthy.  At  theater  level  it  was  reported 
that  it  took  seven  to  ten  days  for  transactions  to  update 

O  A 

the  theater  database  (once  they  had  a  theater  database).'^'' 

An  office  of  the  DCSPER  reported  that  their  data  was  histori- 

A  1 

cally  15  days  old  when  they  received  the  information.  One 
division  described  their  time  delay  to  be  as  much  as  four- 
weeks-plus . One  command  even  reported  their  time  delay  and 
the  consequences  in  terms  of  months.'^ 
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(4)  There  were  many  reasons  explained  for  this  time 
delay  in  processing  transactions.  The  time  lag  between  the 
actual  event  and  the  unit  submitting  the  transaction  was 
often  lengthy. In  many  cases,  the  transactions  were  being 
submitted  in  a  timely  manner,  it  was  just  that  the  CONUS 
sustaining  base  and  Europe  did  not  always  get  the 
transactions  to  process  them.  Consequently,  units  would  have 
to  resubmit  their  transactions.^^  All  agree  that  there  was  a 
huge  time  delay  built  in  by  just  having  to  deal  with  a 
sustaining  base  thousands  of  miles  away.  If  a  unit  had  to 
process  its  transactions  through  the  mail,  it  could  take 
weeks  before  they  updated  the  database.  Whatever  the  reason 
and  however  long  the  time  delay  was,  is  not  so  important  as 
the  consensus  by  all  personnel  managers  that  SIDPERS  was 
never  timely  or  current. 

During  the  war,  automated  personnel  systems  did  not 
adequately  account  for  all  categories  of  reservists  activated 
and  deployed.  There  was  limited  capability  to  do  this  at  the 
top  of  the  system.^®  Unfortunately,  this  capaility  was  not 
designed  into  SIDPERS  for  field  use.^^  Yet,  commanders  and 
personnel  managers  at  all  echelons  needed  to  track  the 
reservists  by  the  categories  under  which  they  mobilized, 
which  included:  Active  Guard  Reserve  (AGR),  Retired  Reserve, 
Individual  Mobilization  Augmentee  (IMA),  Troop  Unit  reservist 
(TPU),  Individual  Ready  Reserve  (IRR),  Temporary  Tour  of 
Active  Duty  (TTAD),  and  RT-12  (released  from  active  duty 
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within  12  months).  SIDPERS  did  not  provide  that  capability 
nor  could  DA  change  it  rapidly  enough  to  incorporate  the 
functionality.  ° 

SIDPERS  provided  no  capability  to  retain  as  a  data 
element  the  reservists '  original  units  with  which  they 
mobilized.  Personnel  managers  used  reservists  as  individual 
replacement  fillers.  They  received  new  assignments, 
sometimes  to  active  Army  units.  Law  requires  reservists  to 
be  released  from  active  duty  not  later  than  the  date  their 
original  mobilizing  unit  is  demobilized.  These  reservists 
could  remain  on  active  duty  only  if  they  volunteered  to 
remain  on  active  duty  in  a  TTAD  status  and  with  consent  from 
the  commander  of  their  original  unit.^^  Unfortunately, 
SIDPERS  provided  no  means  of  tracking  these  reservists 
against  the  demobilization  dates  of  their  original  units. 

SIDPERS  was  not  flexible  enough  to  provide  much  of 
the  unique  information  needed  for  personnel  management 
purposes  during  the  operation  (of  course,  this  was  only  due 
to  the  personnel  community’s  lack  of  foresight  in 
determining  their  wartime  requirements  prior  to  Operation 
DESERT  STORM) .  SIDPERS  was  not  flexible  enough  to  identify 
soldiers  who  were  deployed  vs.  nondeployed,  soldiers 
who  were  affected  by  STOP  LOSS  policies,  soldiers  who  were 

O  1 

attached  vs.  assigned,  or  soldiers  who  were  single  parents. 
Many  units  reported  the  need  for  SIDPERS  to  identify  soldiers 
in  a  TDY  status  or  soldiers  who  were  dual  military  couples. 
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There  was  also  an  interest  in  tracking  some  soldiers  who  were 
deployed  directly  from  Training  and  Doctrine  Command  (TRADOC) 
schools  so  that  they  could  be  sent  back  for  further 
training. 

By  January  1991  a  deployment  indicator  (DPLI)  code 
was  added  to  SIDPERS  for  the  field  to  use.^^  However,  this 
code  was  not  added  till  long  after  most  of  the  units  had  been 
deployed  and  furthermore,  the  code  could  only  be  useful  if 
all  units  had  submitted  transactions  with  their  DPLI  codes. 
Because  the  units  largely  did  not  do  this,  there  still 
existed  no  real  capability  to  distinguish  deployed  vs. 
nondeployed  soldiers. Furthermore,  SIDPERS  did  not  include 
data  elements  indicating  why  a  soldier  was  nondeployable,  if 
the  condition  was  temporary  or  permanent  and,  if  temporary, 
when  they  would  become  deployable. 

Naturally,  units  improvised  ways  to  account  for  these 
different  categories  of  soldiers.  They  came  up  with  SIDPERS 
work  around  solutions.  They  built  their  own  databases  using 
off  the  shelf  software  packages.  And,  in  many  cases,  they 
resorted  to  manual  means. 

Initially,  personnel  automation  failed  to  provide 
strength  roll-up  capability  to  echelons  above  division  (EAD). 
Later,  a  roll-up  capability  was  fielded.  The  Soldier  Support 
Center  (later  assisted  by  the  Total  Army  PERSCOM  and  the  Soft¬ 
ware  Development  Command  -  Washington^®)  deployed  the 


60 


Corps  Prototype  Software  (CPS).  Both  the  XVIII  and  VII  Corps 
used  this  software  during  Operation  DESERT  STORM. This 
extract  database  program  started  with  only  21  data  elements 
but  grew  to  64  data  elements  by  the  end  of  the  conflict.^® 

Unfortunately,  this  new  capability  proved  only 
marginally  successful.  It  failed  to  be  responsive  to  the 
needs  of  the  system  users. 

The  SIDPERS  extract  system  failed  to  provide 
timely  response  times  to  database  queries  at  Corps 
and  Theater.  Even  with  the  abbreviated  database 
extract  at  EAD/Corps/Theater  (64  data  elements), 
response  times  to  queries  were  running  up  to  2  1/2 
hours  on  a  B-38  PC  [TACCS-Enhanced  equipment l  with 
its  386-chip,  20  Mhz  processing  capability . 

At  the  theater  level,  matters  were  complicated  by  the 
decision  by  HQDA  not  to  have  a  database  at  theater  processing 
SIDPERS.  DA  made  the  decision  because  Army  Forces  Central 
Command  (ARCENT)  in  Southwest  Asia  did  not  want  the  burden  of 
keeping  up  a  peacetime  system  (which  might  necessitate 
shipment  of  personnel  records  to  personnel  units  in  theater) 
and  because  the  CONUS  installations  and  Europe  were  already 
providing  mainframe  automation  support.^®  This  decision  was 
made  with  the  full  understanding  that  the  capability  did 
exist  with  the  344th  Data  Processing  Unit  (DPU)  to  process 
SIDPERS  in  theater. The  324th  DPU  was  also  capable  of 
processing  SIDPERS  in  theater. 

By  the  end  of  the  war  the  theater  did  establish  a 
database  with  roll-up  capability  (not  to  be  confused  with 
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SIDPERS  processing  capability)  using  the  Soldier  Support 
Center  extract  database  program.  Nevertheless,  this  provided 
the  theater  with  only  rudimentary  strength  management 
capability.  Later,  to  support  the  residual  force  after  the 
war,  a  SIDPERS  personnel  processing  activity  (PPA)  was 
established  in  the  theater  and  included  connectivity  with 
CONUS  for  mainframe  support. 


Figure  5-2,  below,  shows  the  timeline  for  the 
establishment  of  the  theater  database.  Note  that  prior  to 
February  1991  there  was  not  a  theater  database  at  all.  And 
it  was  not  until  March  1991  that  the  theater  was  able  to 
completely  account  for  the  force.  The  theater  database  was 
fully  functional  just  as  units  were  beginning  to  redeploy 
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Interfaces 


The  SIDPERS  interface  with  the  Mobilization  Personnel 
System  (MOBPERS)  did  not  allow  the  necessary  flexibility 
needed  to  support  mobilization.  MOBPERS  did  pass 
prepositioned  skeletal  accession  data  to  mobilization 
stations.  However,  mobilization  stations  ecountered  three 
primary  limitations.  First,  they  had  to  "handjam"  accession 
data  for  soldiers  mobilized  at  other  than  their  doctrinally 
defined  mobilization  stations.  Second,  SIDPERS  could  only 
use  MOBPERS  data  when  accessioning  an  entire  unit  or  a 
soldier  by  personnel  mobilization  code.  Third,  the  MOBPERS 
data  proved  to  be  insufficient  for  accession/personnel 
management  purposes. 

Much  of  the  MOBPERS  data  was  not  current  and  had  to 
be  keyed  manually  into  SIDPERS.  For  example,  there  were 
outdated  specialties  and  additional  skill  identifiers.  Skill 
levels  and  grades  did  not  always  match. Furthermore, 
additional  data,  like  basic  branch,  had  to  be  manually  keyed 
into  SIDPERS. Consequently,  mobilization  stations  kept 
very  busy  trying  to  ensure  that  they  properly  accessioned  the 
mobilizing  reservists  into  SIDPERS. 

During  the  entire  operation,  the  use  of  derivative 
unit  identification  codes  (UICs)  became  an  improvised  means 
for  activating,  deploying,  and  accounting  for  portions  of 
units.  The  only  approved  source  for  unit  level  organization 
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data  for  automated  personnel  systems  is  the  Status  of 
Resources  and  Training  System  (SORTS).  Units  are  registered 
in  SORTS  and  tracked  through  the  personnel  systems  by  UICs. 
Early  in  deployment,  Forces  Command  (FORSCOM)  determined  that 
in  some  cases  only  portions  of  some  reserve  units  should  be 
activated  as  the  units'  full  capabilities  were  not  needed. 
Consequently,  HQDA  approved  the  mobilization  of  partial  units 
by  creating  derivative  UICs.^®  This  approach  was  later  used 
for  rear  detachments  to  distinguish  them  from  the  main  body 
of  the  units  deployed.  In  Southwest  Asia,  derivative  UICs 
were  also  used  for  medical/replacement  holding  purposes. 


Initially  an  automated  interface  did  not  exist 
between  SIDPERS  and  postal  operations.  Postal  units  had  an 
impossible  mission  of  tracking  people  for  much  of  the 
operation  without  the  benefit  of  an  automated  postal  locator 
and  interface  with  SIDPERS. 

The  direct  and  general  support  postal  units 
arrived  in  theater  without  authorization  for  hardware 
and/or  software  needed  to  redirect  mail.  The 
equipment  required  is  not  part  of  their  TO&E  [Table 
of  Organization  and  Equipment]  or  postal  equipment. 
Without  an  established  theater  data  base  linkage  or 
the  means  to  build  their  own,  the  redirect  mission 
quickly  grew  beyond  the  ability  to  respond. .. .The 
Army  needs  a  system  to  account  for  individuals  in  the 
AOR  [Area  of  Responsibility].  The  system  needs  to  be 
available  to  postal  units  and  in  a  format  they  can 
use  to  find  individuals  and  build  units  schemes  to 
support  their  redirect  mission.^® 

Of  course,  SIDPERS  was  that  Army  system  which  was  supposed  to 

account  for  individuals  and  an  automated  postal  locator  would 

have  provided  the  format  postal  units  needed  to  accomplish 
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their  redirect  mission.  In  fact,  later  in  the  operation, 
hardware  and  programing  support  was  provided  by  Total  Army 
PERSCOM  and  the  344th  DPU  for  this  purpose.  They  established 
an  automated  postal  locator  and  interface  with  the  theater 
database  providing  a  long  awaited  relief  for  the  postal 
community.’^  In  any  case,  with  the  volume  of  mail 
approximately  2  1/2  times  historical  planning  figures,  it  is 
amazing  postal  operations  worked  as  well  as  they  did  using, 
for  much  of  the  operation,  primarily  manual  methods  and 
procedures . 

An  Automated  interface  also  did  not  exist  between 
SIDPERS  and  the  Theater  Army  Medical  Management  Information 
System  (TAMMIS).  This  interface  might  have  been  beneficial 
in  accounting  for  soldiers  evacuated  to  the  hospitals. 


The  status  and  accountability  for  casualties  was 
largely  lost  when  medical  personnel  evacuated  them  to 
hospitals . 

Once  a  unit  evacuates  a  casualty  to  a  medical 
unit  or  when  treatment  begins,  the  parent  unit  S-1 
and  G-1  personnel  channels  are  no  longer  able  to 
track  the  progress  or  location  of  their  unit  member. 
Telephonic,  radio  traffic,  or  personal  visitation  by 
CDRS,  ISGs,  S-ls,  ET  AL,  are  required.  There  is 
little  hope  of  successfully  obtaining  timely, 
accurate  information  and  data  on  the  patient.^^ 

This  lack  of  accountability  for  the  soldiers  in  the  hospitals 

was  even  further  complicated  by  the  number  of  treatment 

facilities  servicing  the  soldiers. 

The  battalion  experienced  some  difficulties  in 
accounting  for  personnel  undergoing  treatment  at 
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various  evac  hospitals  and  related  facilities.  The 
problem  was  compounded  by  the  sheer  number  of 
facilities  located  in  our  support  area.  In  instances 
where  unit  members  were  attached  forward  the  parent 
unit  was  not  always  able  to  be  notified  when  an 
individual  soldier  was  injured  and/or  taken  to  a 
medical  facility.  The  process  of  checking  individual 
facilities  by  phone  is  tedious  at  best.^^ 

The  medical  community  often  evacuated  soldiers  completely  out 

of  Southwest  Asia  without  commanders  or  the  home  stations 


even  knowing. 


Soldiers  who  were  injured  or  developed  medical 
problems  in  Southwest  Asia  were  routinely  MEDEVACed 
[medically  evacuated]  to  USAREUR  [US  Army  Europe] 
with  no  notice  to  the  Rear  Detachment.  Once  a 
soldier  left  the  unit,  he/she  was  managed  through 
medical  channels.  Soldiers  not  critically  injured 
returned  to  USAREUR  without  the  Rear  Detachment  or 
Community  being  aware  of  their  status. 


Eventually  personnel  units  had  to  locate  liaisons  at  the 
different  hospitals  to  intercept  the  soldiers  being  admitted 
and  then  report  their  status  through  personnel  channels. 


An  interface  between  SlDPERS  and  the  medical 
information  system  may  work  for  future  conflicts  but  in 
reality  the  interface  would  have  done  little  to  help  during 
Operation  DESERT  STORM.  "TAMMIS . . . was  only  operational  in 
one  theater  hospital  and  therefore  was  not  effective. 
Fortunately,  there  were  few  casualties.  Nevertheless,  there 
was  the  potential  for  large  numbers  of  casualties  to  have 
made  casualty  accountability  by  the  personnel  community  a 
serious  problem. 


Operation  DESERT  STORM  demonstrated  a  need  to  account 
for  civilian  personnel  deployed  to  the  theater.  As  it  turned 
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out,  there  was  no  automated  system  to  account  for  them  while 
they  were  deployed. 

...a  capability  must  be  developed  to  support 
civilians  after  deployment,  either  through  a  deployed 
version  of  the  civilian  system  or  as  an  adjunct  to 
the  military  system. 

If  DA  determines  that  civilian  accountability  will  be 
maintained  by  the  military  personnel  system  (SIDPERS),  then 
an  interface  with  the  peacetime  Automated  Civilian  Personnel 
System  (ACPERS)  would  be  beneficial.  However,  in  the  short 
term,  it  would  probably  be  easier  to  deploy  the  ACPERS 
system,  rather  than  make  massive  changes  to  SIDPERS. 


Operation  DESERT  STORM  also  demonstrated  the  need  to 
relook  the  interfaces  that  exist  between  those  systems 
designed  to  manage  structure  and  the  military  personnel 
management  systems.  Earlier  in  the  chapter,  the 
functionality  issue  of  authorized  and  required  strength 
accounting  was  addressed.  The  interface  between  The  Army 
Authorization  Document  System  (TAADS)  and  the  personnel 
management  systems  like  SIDPERS  made  this  functionality 
possible.  Unfortunately,  this  interface  just  did  not 
allow  the  needed  flexibility  for  less  than  full 
mobilization.  SIDPERS  needs  to  be  able  to  select  individual 
units  being  mobilized  and  update  the  database  with  their 
authorized  or  required  strength. 

The  automated  interfaces  that  exist  between  the 
Army's  system  for  managing  structure  and  the 
personnel  management  system  did  not  support  DESERT 
SHIELD/STORM.  These  interfaces  must  be  modern¬ 
ized.  . . .A  major  effort  will  be  required  to  examine 
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the  existing  automated  interfaces  and  develop  a  new 
set  of  functional  requirements.  ' 


Hardware 


All  the  Army  units  deployed  did  not  use  TACCS.  This 
was  especially  true  of  reserve  units.  Reserve  component 
units  were  placed  at  the  end  of  the  fielding  schedule, 
behind  the  active  component  units.  At  the  time  of  the  war, 
only  28%  of  the  reserve  units  had  TACCS. 

Moreover,  the  Army's  decision  to  stop  further 
procurement  of  the  TACCS  has  left  hundreds  of  reserve 
component  units  in  the  inventory  without  the  basic 
tool  required  to  plug  into  the  Active  Army  personnel 
system. 

What  compounded  the  low  fielding  percentage  even  more  was 
that  before  Operation  DESERT  STORM  the  fielding  of  TACCS  had 
been  to  the  wrong  units.  For  the  most  part,  the  RC  units 
deployed  were  combat  support  and  combat  service  support  units 
while  only  RC  combat  arms  units  had  received  TACCS.®® 


Reserve  units  were  not  fully  trained  on  TACCS,  or  on 
the  SIDPERS  application  for  the  TACCS.  Those  units  which 
were  fortunate  enough  to  have  TACCS  before  Operation  DESERT 
STORM  did  not  use  the  equipment  regularly  and,  consequently, 
the  training  they  once  received  was  lost. 

Reserve  Component  units  that  have  TACCS  equipment 
only  received. . .training  during  initial  extension  of 
the  TACCS  to  the  unit.  It  appears  proficiency  was 
lost  after  this  first  training  period.  Several  RC  units 
required  retraining. . .before  deployment.  The  training 
conducted  prior  to  the  DESERT  SHIELD  deployment  was  on 
unit  TACCS  equipment.  However,  in  many  cases,  the 
equipment  wasn't  available  because  it  was  being  prepared 
for  shipment.®^ 


68 


Because  many  of  these  TACCS  equipped  reserve  units  mobilized 
at  non-TACCS  equipped  mobilization  stations,  getting  any  kind 
of  refresher  training  was  impossible.  Unfortunately,  all 
efforts  to  provide  training  during  the  war  proved  largely 
ineffective. 

Many  units  did  not  like  the  TACCS  hardware.  It  was 
generally  despised  for  its  size.  The  keyboard  is  not 
standard.  And  it  is  old  technology.  Generally  personnel 
units  would  like  to  see  the  Army  transition  to  lap  top 
hardware  with  MS  DOS  compatibility.^^  Otherwise,  they  would 
rather  use  their  own  off  the  shelf  commercial  hardware  and 
software. 

The  corps  and  theater  levels  did  not  use  CTASC  IIs. 
This  was  only  because  the  equipment  had  not  yet  been  fielded 
to  the  personnel  units  requiring  the  equipment  by  doctrine. 
CTASC  I  equipment  was  available  at  the  theater  level  and  it 
also  came  equipped  with  the  SIDPERS  software,  however,  it  was 
never  utilized  either  for  SIDPERS  processing  or  to  provide 
the  theater  with  its  own  strength  management  capability.®'^ 
Instead,  both  the  corps  and  theater  levels  used  TACCS- 
Enhanced  equipment  late  in  the  operation  to  provide 
rudimentary  roll-up  capability  and  strength  management 
functionality.  Although  the  TACCS-Enhanced  equipment 
provided  enhanced  data  storage  and  processing  capability  over 
the  TACCS,  it  still  was  not  sufficient  for  timely  processing 

fi  S 

at  the  corps  and  theater  levels. 
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Communications 


Probably  communications  varied  the  most  from 
personnel  doctrine.  Most  units  and  personnel  elements  did 
not  have  the  capability  to  transmit  data  electronically. 

This  was  probably  most  true  of  the  combat  service  support  and 
reserve  units. 


Many  units  had  only  one  tactical  radio  in  a 
company  of  120  personnel.  Additionally,  the 
percentage  of  fill  of  tactical  radios  and  voice 
secure  equipment  was  under  fifty  percent.  The 
percent  of  fill  for  reserve  component  units  was  even 
less.®® 


Furthermore,  tactical  communications  equipment  needed  to  be 
dedicated  for  just  personnel  reporting  and  data  transmission. 

Sis  need  a  dedicated  radio  capability  to  transmit 
strength  data  to  the  brigade  SI  and  casualty  data  to 
the  PSC  in  the  DSA  [Division  Support  Area].  Communi¬ 
cations  between  the  Brigade  SI  and  PSC  as  well  as  the 
G1  and  PSC  are  also  required.®' 


Without  tactical  communications  equipment,  units  and 
personnel  elements  resorted  to  whatever  means  possible  to 
pass  on  their  personnel  data  and  strength  reports  to  the 
higher  echelons  within  theater. 

With  no  internal  communications  capabilities, 
personnel  strength  accounting  was  difficult  to 
impossible.  The  host  nation  telephone  system  did  not 
allow  a  direct  call  from  the  Headquarters  to  portions 
of  the  unit  located  elsewhere  in  the  country. 

Valuable  time  was  wasted  relaying  calls  through 
various  locations  to  obtain  or  transmit 
information . ®° 

In  fact,  even  the  transfer  of  data  by  way  of  courier  was 
difficult  due  to  long  distances  between  units.  Battalion  Sis 
in  combat  trains  were  50-200  km  ahead  of  their  PACs  in  the 
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field  trains.  PSCs  were  usually  too  far  behind  to 
communicate  with  supported  maneuver  units.  Couriers  were 
impractical  and  untimely.®^ 

Because  CONUS  installations  and  Europe  provided 
peacetime  mainframe  support  to  the  units  deployed,  personnel 
service  companies  had  to  send  their  SIDPERS  transactions  back 
to  CONUS/Europe .  This  too  they  accomplished  by  whatever 
means  possible  to  include:  mail;  telephone;  courier;  and,  if 
lucky,  data  communications.  Unfortunately,  dealing  with  the 
support  base  thousands  of  miles  away  proved  very  difficult, 
for  some  personnel  units  almost  impossible.  An  illustration 
of  the  Operation  DESERT  STORM  communications  flow  is  at 
Figure  5-3  below. 


Figure  5-3 
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For  the  most  part,  data  communications  between 
Southwest  Asia  and  CONUS  had  to  be  patched  together. 
Initially,  tactical  communications  could  not  be  transmitted 
through  the  Defense  Data  Network  (DDN).  The  Personnel 
Information  Systems  Command  (PERSINSCOM)  and  in-theater 
signal  assets  installed  "BLAST"  DDN  software  enabling  TACCS 
to  TACCS  communications  between  XVIII  Airborne  Corps  and  Ft. 
Bragg. Signal  assets  and  PERSINSCOM  also  installed  remote 
job  entry  stations  for  satellite  transmission  of  data  from 
theater  back  to  CONUS. The  data  communication  flow  that 
was  finally  followed  late  into  the  operation  is  illustrated 
in  Figure  5-4  below. 
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Chapter  ^  Conclusions 


During  Operation  DESERT  STORM  the  personnel  community 
did  not  always  follow  doctrine.  Much  of  the  time  they 
just  could  not  implement  it.  Functional  expectations  were 
very  demanding  on  the  personnel  community.  The  software 
proved  largely  inflexible,  untimely,  difficult  to  use,  and 
unable  to  track  all  categories  of  soldiers.  Many  critical 
interfaces  were  either  nonexistent  or  they  did  not  fully 
support  the  needs  of  personnel  managers  at  all  levels  of  the 
Army.  The  hardware  was  not  fully  fielded  and  where  it  was, 
it  was  not  always  used.  And  finally,  communications  were 
scarce  and  had  to  be  patched  together.  In  order  for  units 
and  personnel  elements  to  make  personnel  accounting  and 
strength  reporting  work  at  all  they  had. to  improvise 
variations  from  doctrine. 

Naturally,  problems  resulted  with  each  variation  from 
doctrine.  So  significant  were  some  of  the  problems  that 
it  is  questionable  whether  the  personnel  community  ever  had 
control  over  personnel  accounting  and  strength  reporting 
during  the  war.  Certainly,  it  will  take  the  Army  many 
months,  or  even  years,  to  fully  recover  from  the  ill  effects 
of  personnel  automation  during  the  war. 
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interview  notes  in  author's  possession,  17  &  18  March  1992. 

^^PERSCOM,  III-H-3. 

^^CALL,  JULLS  Number:  32027-85035. 

^^Oscar  Ithier,  Sergeant  First  Class,  telephone  interview 
with  him  concerning  his  background/experiences  while  he 
served  with  XVIII  Airborne  Corps  Automation  Branch,  interview 
notes  in  author's  possession,  23  March  1992. 

^"^PERSCOM,  III-H-5. 

^®CALL,  JULLS  Number:  52067-86593  (00054). 

^^CALL,  JULLS  Number:  60344-15290  (00007). 

2°USARCENT,  Vol.  15,  10th  PERSCOM,  unknown. 

^^CALL,  JULLS  Number:  01628-85115  (00052). 

^^CALL,  JULLS  Number:  32019-60109. 

^^USARCENT,  VOL  17,  11  Signal  Command,  Part  III,  116. 

^^Emily  B.  Graves,  Captain,  telephone  interview. 

2  5 

Larry  Proctor,  Lieutenant  Colonel,  telephone  interview 
with  him  concerning  his  knowledge/experiences  while  he  served 
as  commander  of  the  344th  Data  Processing  Unit  (DPU), 
interview  notes  in  author's  possession,  23  March  1992. 

Emily  B.  Graves,  Captain,  telephone  interview. 

o  7 

John  E.  Brady,  telephone  interview. 

^®PERSCOM,  III-H-3. 

'^"Jam  Nicholas,  Sergeant  Major,  telephone  interview 
concerning  his  knowledge/experiences  while  working  in  the 
ARCENT  Reserve  Liaison  Office,  interview  notes  in  author's 
possession,  18  March  1992. 

^°CALL,  JULLS  Number:  32555-96166  (00052). 

^^PERSCOM,  III-H-3. 
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^William  M.  Turner,  Sergeant  Major,  telephone  interview 
concerning  his  knowledge/experiences  while  working  in  the 
24th  Personnel  Service  Company  (PSC),  24  Infantry  Division, 
interview  notes  in  author's  possession,  24  March  1992. 

Emily  B.  Graves,  Captain,  telephone  interview, 

^^Christine  Palmer,  Chief  Warrant  Officer  3,  telephone 
interview  concerning  her  knowledge/experiences  while  working 
in  the  344th  DPU,  interview  notes  in  author's  possession, 

5  March  1992. 

^^CALL,  JULLS  Number:  32681-23079  (00062). 

O  £ 

Emily  B.  Graves,  Captain,  telephone  interview. 

^^US  Army  Soldier  Support  Center  (SSC),  Operation  DESERT 
SHEILD/STORM  After  Action  Review  (Ft.  Leavenworth,  KS : 
Department  of  the  Army,  August  1991),  not  numbered. 

3®PERSC0M,  III-H-8. 

^^PERSCOM,  III-H-8. 

^*^Lawrence  J.  Adair,  Colonel,  telephone  interview  while 
he  was  at  PERSCOM,  interview  notes  in  author's  possession,  1 
November  1991. 

^^Christine  Palmer,  Chief  Warrant  Officer  3,  telephone 
interview. 

^^John  E.  Brady,  telephone  interview  while  he  worked  at 
Field  Systems  Directorate,  PERSCOM,  interview  notes  in 
author's  possession,  23  April  1992. 


^^PERSCOM, 

III-H-5. 

^^CALL,  JULLS  Number: 

01230-08197 

(00076) . 

^ ^PERSCOM, 

III-H-5. 

^®US  Army, 

Center  for 

Army  Lessons 

Learned  (CALL),  Desert 

STORM  Special  Study  Project,  General  Officer  Steering 
Committee  (Ft.  Leavenworth,  KS;  Department  of  the  Army,  9 
July  1991),  2. 

^^US  Army,  Headquarters,  10th  PERSCOM,  Briefing,  PERSCOM 
AAR,  (Ft.  Leavenworth,  KS:  Department  of  the  Army,  1991), 
not  numbered. 

'^^CALL,  JULLS  Number;  51660-39189  (00005). 

^^Larry  Proctor,  Lieutenant  Colonel,  telephone  interview. 
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^°CALL,  JULLS  Number:  51660-39189  (00005). 

^^CALL,  JULLS  Number:  62136-06616  (00265). 

C  O 

US  Army,  Headquarters,  VII  Corps,  VI I  Corps  Desert 
Campaign  After  Action  Report ,  Vol .  241,  2d  COSCOM,  Part  3, 
(Ft.  Leavenworth,  KS :  Department  of  the  Army,  August  1991), 
26. 

^^CALL,  JULLS  Number:  16868-36900  (01286). 

^'^USARCENT,  Vol  2,  Tab  A  (Gl-AG),  1. 

^^ODCSPER,  5. 

^^PERSCOM,  III-H-5. 

^^ODCSPER,  5. 

^^PERSCOM,  III-H-1. 

^^CALL,  JULLS  Number:  60344-15290  (00007). 

^^PERSCOM,  III-H-1. 

®^CALL,  JULLS  Number  51757-38708  (00023). 

®2pERSCOM,  III-H-1. 

®^US  Army  Combined  Arms  Support  Command,  Operation  Desert 
SHIELD/STORM  Observations  and  Related  Data  (Ft.  Lee,  VA: 
Department  of  the  Army,  August  1991),  Topic:  TACCS. 

®^John  E.  Brady,  telephone  interview  while  he  was  at 
Field  Systems  Directorate,  PERSCOM,  notes  of  interview  in 
possession  of  author,  21  February  1992. 

^^PERSCOM,  III-H-8. 

^®CALL,  JULLS  Number  62238-95557. 

^"^SSC,  2. 

®®USARCENT,  Vol  10,  416  Engineer  Command,  23. 

®^SSC,  2. 

"^^PERSCOM,  11-17. 

"^^PERSCOM,  11-17. 
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FIGURES 


5-1  -  US  Army,  ODCSPER,  Briefing  of  ODCSPER  Mobilization 
Automation  Task  Force  Action  Plan  (Washington,  DC: 

Department  of  the  Army,  August  1991)- 

5-2  -  US  Army,  Field  Systems  Directorate  (FSD),  PERSCOM, 
Working  Papers  (Washington  DC:  Department  of  the  Army, 
August  1991 ) . 


5-3  -  FSD, 

PERSCOM, 

working 

papers . 

5-4  -  FSD, 

PERSCOM, 

working 

papers . 
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CHAPTER  6 


IMPACTS  FROM  NONCOMPLIANCE  WITH  DOCTRINE 

This  chapter  describes  the  consequences  of 
noncompliance  with  doctrine.  There  were  many  problems  that 
resulted  from  the  personnel  community's  inability  to  satisfy 
doctrinal  expectations.  In  many  cases  the  doctrine  just 
could  not  be  implemented.  The  disconnect  between  actual 
practice  and  doctrine  resulted  in  serious  backlogs,  increased 
workloads,  extensive  processing  delays,  lost  accountability, 
noncurrent  data,  inaccurate  data,  system  nonresponsiveness, 
reporting  inconsistencies,  ineffective  personnel  management, 
and  of  course  service  delays  to  the  soldiers.  This  chapter 
addresses  each  of  these  impacts  in  greater  detail. 

Functionality 

Department  of  the  Army  decided  not  to  implement 
wartime  doctrine  by  requiring  the  continuation  of  peacetime 
procedures  and  policies  during  the  Gulf  War.  This  resulted 
in  an  added  workload  for  personnel  units/elements  in 
Southwest  Asia  at  a  time  when  their  focus  should  have  been 
only  on  wartime  functionality.  In  fact,  personnel 
units/elements  had  to  support  wartime  functionality, 
peacetime  functionality,  and  the  peculiarities  of  all  Army 
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components  (Active  Army,  Army  National  Guard,  US  Army 
Reserve),  while  also  having  to  keep  up  with  all  the  units  on 
the  move  and  their  constantly  changing  command  alignments. 
One  brigade  SI  explained  that  they  found  they  had  to  do  more 
with  less  and  in  less  time.^ 


Problems  were  further  compounded  by  having  to  deal 
with  a  sustaining  base,  located  thousands  of  miles  away, 
which  made  coordination  extremely  difficult.  In  many  cases 
it  was  next  to  impossible.  The  impact  on  the  promotion 
system  alone  was  especially  tragic. 

The  system  used  to  process  promotions  was 
cumbersome  and  labor  intensive. .. .The  processing  took 
up  to  90  days.  It  often  required  extensive 
transcontinental  communications  between  the  PSC  and 
their  rear  detachment....^ 

One  major  command,  concerned  with  the  impact  of  this  delay  in 
processing  promotions,  explained: 

The  recovery  period  needed  to  fix  the  promotion 
system  and  restore  the  quality  of  personnel 
information  can  now  be  expected  to  take  several 
months.  A  number  of  soldiers  will  probably  never 
recover  lost  time  in  grade,  pay,  and  documentation.^ 


Active  component  (AC)  personnel  units  also  expressed 
difficulties  in  dealing  with  reserve  component  soldiers  on 
active  duty.  They  found  it  difficult  to  provide  them  with 
the  level  of  personnel  service  support  they  deserved. 
Dissatisfied  with  the  support  to  the  reserve  component,  the 
theater  reserve  component  (RC)  liaison  office  explained, 

PSS  for  the  RC  in  the  theater  was  totally 
inadequate.  It  was  as  if  the  AC  leadership  abrogated 
any  responsibility  to  RC  soldiers  in  this  regard. 
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RC  personnel  units  were  placed  in  general  support 
under  AC  direction  and  devoted  little  attention  to 
RC-specific  problems ... .To  ignore  the  PSS  needs  of  a 
third  of  the  force  is  lunacy.  The  long-range 
consequences  of  this  serious  short-sightedness  will 
be  difficult  and  expensive  to  overcome.'^ 


Having  to  support  peacetime  and  wartime  functionality 
as  well  as  all  components,  and  under  difficult  circumstances, 
not  only  created  a  heavy  workload  for  personnel  units/ele¬ 
ments,  but  it  added  to  their  inability  to  operate 
effectively.  They  just  could  not  support  all  their 
requirements  and  do  any  one  of  them  justice.  With  so  much  to 
do,  they  were  distracted  from  performing  their  most  important 
responsibilities,  their  wartime  functions. 


The  decision  to  manage  the  force  by  authorizations, 
as  opposed  to  required  strengths,  created  serious  problems 
for  the  personnel  community  and  the  ability  of  automation  to 
support  personnel  accounting  and  strength  reporting. 

Automated  authorization  data  for  reserve 
component  units  was  not  available.  The  automated 
interface,  MOBTAADS  [a  subset  of  TAADS  used  to 
integrate  mobilizing  units  into  the  active  Army]  was 
unable  to  convert  from  a  requirements  base  to  an 
authorization  base.  Thousands  of  manhours  were 
expended  to  manually  load  authorization  data  at  the 
MS  [mobilization  stations].  In  many  instances, 
however,  the  data  was  simply  not  loaded  for  lack  of 
time  and/or  documentation.  Because  of  this  major 
shortcoming  it  was  virtually  impossible  to  get 
visibility  on  aggregate  authorizations  in  the 
echelons  above  the  division.^ 

Vertical  The  Army  Authorization  Document  System  (VTAADS) 

supplies  authorization  data  for  only  active  Army  units,  not 

for  reserve  component  units.  Mobilization  The  Army 
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Authorization  Document  System  (MOBTAADS)  supplies  only 
required  data  for  all  Army  units. ^  The  decision  to  activate 
reserve  units  at  authorized  vs.  required  strengths  forced  the 
mobstations  to  load  the  data  manually  since  it  could  not  be 
supplied  by  either  VTAADS  or  MOBTAADS.  This  manual  loading 
of  data  created  a  heavy  workload  requirement  on  the  already 
overtaxed  mobilization  stations.  Also,  because  the  data 
loaded  by  the  mobilization  stations  was  not  always  complete, 
it  seriously  impacted  the  accuracy  of  the  personnel  data 
bases . 


Matters  were  made  worse  because  initially  there  was 
no  guidance  as  to  what  level  of  authorized  manning  was 
required  for  deployment.  "This  wreaked  havoc  in  the  field, 
as  FORSCOM  cross-leveled  across  MACOM  [major  commands] 
without  DA  guidance."^  Consequently,  units  received 
personnel  fill  and  were  deployed  at  different  levels  of 
authorizations  from  ALO  1  (the  wartime  required 
strength)  to  ALO  3  (a  considerably  lower  authorization 
level).®  Unfortunately  personnel  units/elements  in  Southwest 
Asia  had  to  manage  personnel  strengths  by  the  obvious 
inconsistencies  in  the  authorization  levels  for  the  different 
types  of  units. 

Without  task  force  accountability,  automated 
personnel  systems  provided  little  value  to  the  battlefield 
commander.  Units  committed  to  battle  usually  went  as  part  of 
a  task  force.  Commanders  needed  to  be  able  to  rely  on 
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personnel  managers  for  the  personnel  status  of  each  task 
force.  This  information  was  vital  for  the  purpose  of 
supporting  tactical  decisions.  Without  task  forcing 
capability  within  personnel  automation  systems,  personnel 
managers  had  to  resort  to  more  time  consuming  means  to 
provide  the  information  to  their  commanders.  Commanders  were 
not  happy  with  these  delays  and  seeming  lack  of 
responsiveness  by  the  personnel  community.  Reasonable 
demands  by  commanders  for  routine  personnel  information  could 
not  be  met.  In  fact,  personnel  managers  did  not  satisfy  all 

q 

requests  properly.^ 

The  delay  in  deploying  personnel  assets  to  the 
theater  also  had  a  serious  impact,  not  only  on  automation 
support  of  personnel  accounting  and  strength  reporting  but 
also  on  other  personnel  functions.  With  regard  to  combat 
service  support  (CSS)  units  (among  which  are  personnel  units) 
it  was  reported  that  serious  backlogs  developed  because  the 
CSS  units  were  not  in  the  theater  to  manage  and  handle  the 
deployment  flow.^®  Personnel  units/elements,  because  they 
were  often  not  in  theater  to  support  the  deployment,  had  to 
prepare  transactions  covering  past  events/accountability  when 
they  did  arrive  in  theater.  Personnel  units/elements  had  to 
play  catch  up  to  regain  accountability  of  the  force. 

According  to  JULLS  reports,  the  late  deployment  of  personnel 
units/elements  directly  contributed  to  many  of  the  personnel 
service  support  (PSS)  problems  experienced,  including 
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problems  in  strength  management,  postal  operations,  and 
replacement  operations . Late  deployment  of  personnel 
units/elements  especially  affected  personnel  accountability 
as  reflected  in  the  following  statement: 

...failure  to  deploy  a  supporting  personnel 
element  early  in  the  deployment ...  further  degraded 
the  accuracy  of  personnel  accountability ....  The  personnel 
accounting  system  never  fully  recovered,  resulting  in 
strength  management  and  top-of-the-system  reporting 
delays  throughout  the  deployment . 

Overall,  the  consequences  of  the  late  deployment  of  personnel 

assets  were  excessive  backlogs  and  lost  accountability 

from  which  the  personnel  community  never  recovered. 

Personnel  databases  were  inaccurate  and  accountability  for 

the  force  was  never  complete. 


Serious  difficulties  occurred  in  personnel 
functionality  in  general,  due  to  the  late  deployment/ 
organization  of  the  theater  PERSCOM.  Theater  policies  and 
standard  procedures  were  badly  needed  for  all  personnel 
functional  areas  including  personnel  accounting  and  strength 
reporting. 

Theater-level  direction  of  the  military  personnel 
management  system  was  especially  weak  during  the 
early,  critical  months  of  the  operation  primarily 
because  the  Personnel  Command  was,  for  all  practical 
purposes,  nonexistent.  The  small  contingent  of 
personnel  initially  deployed  as  part  of  the  Support 
Command  were  unable  to  keep  pace  with  or  resolve 
theater  level  issues. 

By  the  time  a  theater  PERSCOM  was  fully  operational  personnel 
functionality  had  suffered  immensely. 

By  the  time  the  theater  PERSCOM  was  in  theater 
and  organized  to  execute  its  missions,  postal 
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operations  were  completely  overwhelmed,  no  casualty 
reporting  system  was  in  place,  and  no  assistance  had 
been  provided  to  streamline  theater  replacement 
operations . 


Personnel  units/elements  expressed  the  need  for  a 
fully  integrated  automated  personnel  system  between  all  three 
components  many  times .  Lack  of  standard  data  made  the 
transition  to  the  active  component  SIDPERS  very  difficult  for 
the  reserve  component.  Reservists  also  had  a  corresponding 
difficulty  working  with  the  active  component  SIDPERS  because 
their  own  automated  personnel  systems  were  vastly  different. 

The  absence  of  a  single,  modern,  and  integrated 
personnel  information  management  system  for  use  in 
managing  the  total  force  degraded  the  personnel 
readiness  decision  process  and  severely  taxed  the 
personnel  community  at  installation,  CONUSA 
[Continental  United  States  Army],  FORSCOM,  and  HQDA 
level . 

Even  though  a  fully  integrated  system  may  never  be  possible, 
a  single  source  database  (TAPDB)  with  standardized  data 
elements  is  possible,  and  would  have  eased  mobilization 
considerably  during  Operation  DESERT  STORM  had  it  been  fully 
operational . 


Software 


Maintaining  the  SIDPERS  peacetime  system  proved 
difficult  for  personnel  units/elements  assigned  in  support  of 
Operation  DESERT  STORM. 

Automated  peacetime  strength  management  systems 
were  unable  to  meet  the  demands  of  personnel 
readiness ....  For  the  most  part,  strength  managers  at 
all  levels  were  forced  to  revert  to  labor  intensive, 
manual  systems  of  questionable  accuracy.^® 
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Also,  when  HQDA  decided  not  to  go  to  SIDPERS-Wartime,  they 
forced  personnel  units/elements  to  keep  up  with  many  of  the 
peacetime  SIDPERS  transactions  that  had  to  be  sent/ 
transmitted/coordinated  with  the  sustaining  base.  The 
personnel  community: 

. . .was  forced  to  manage  a  cumbersome  data  disc 
processing  system,  involving  mailing  or  transport  by 
courier  of  all  SIDPERS  data  discs  to  CONUS.  This 
system  is  unsatisfactory  from  a  soldier  support  stand 
point,  and  results  in  late  promotions  and  other 
important  soldiers  actions  which  directly  impact  on 
troop  morale.^' 

Consequently,  the  primary  results  of  the  decision  to  maintain 
peacetime  SIDPERS  were  increased  workloads  and  extensive  time 
delays  in  processing  data  transactions. 


Although  the  TACCS  C2SRS  software  was  available,  many 
units  relied  on  other  means  to  satisfy  personnel 
accountability  and  strength  reporting  requirements.  This  was 
especially  true  of  reserve  component  units.  Of  course,  this 
led  to  a  lack  of  standardization  and  inconsistencies  in 
reporting. 

The  results  of  this  undiscipline  in  the  personnel 
system  were  inconsistent  accounting  for  personnel  and 
documentation  of  units  authorized  strengths.  These 
inconsistencies  adversely  impacted  both  the  deployed 
force  and  the  top-of-the-system  databases .. .Allowing 
field  commands  to  build  "roll-your-own"  personnel 
systems  on-the-fly  will  result  in  the  same  inability 
to  do  the  job  in  a  consistent,  coherent  manner  for 
the  next  deployment.^® 


Overall  the  C2SRS  software  proved  to  be 
ineffective.  It  was  too  complicated  for  soldiers  to  use. 
Consequently,  there  was  little  or  no  benefit  derived  in  terms 
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of  time  savings  and  accuracy.  One  positive  thing  which  came 
from  its  use  during  the  war  was  experience  based  knowledge  of 
how  to  fix  it. 


The  lack  of  timely  and  current  data  processed  through 
SIDPERS  effected  many  personnel  functional  areas.  This  is 
probably  no  better  exemplified  than  with  promotions. 

Since  finance  is  directly  linked  into  the  SIDPERS 
system,  the  most  significant  problem  encountered  in 
this  process  was  the  promotion  of  Private  First  Class 
to  Specialist.  Once  the  submission  was  made,  it 
would  take  several  months  before  the  soldier  saw  a 
pay  raise.  Each  month  that  the  pay  raise  wasn't 
there  resulted  in  a  pay  inquiry  by  the  soldier. 


Another  good  example  was  the  assignments  process. 
Crossleveling/assignment/replacement  decisions  were  often 
based  on  the  latest  automated  strength  reports  and  personnel 
requisitions  (personnel  requirements  reports).  If  the  data 
was  not  current  then  decisions  may  not  have  been  appropriate. 
Some  units  may  have  been  given  too  many  replacements  while 
others  units,  desperately  needing  relief,  may  have  been 
without.  Many  other  personnel  functional  areas  were 
similarly  affected  by  the  lack  of  timely  and  current  SIDPERS 
data. 


The  inability  of  SIDPERS  to  track  all  categories  of 
reservists,  activated  and  deployed,  had  a  devastating  impact 
on  support  to  these  soldiers.  The  theater  reserve  liaison 
office  described  the  impact  best. 

The  absence  of  accurate  personnel  and  unit 
accounting  data  plagued  nearly  every  facet  of  theater 
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operations  and  affected  the  majority  of  deployed  RC 
PSS  functions.  Major  morale  issues  such  as  mail 
delivery  and  timely  Red  Cross  notification  of  family 
emergencies  were  sometimes  nearly  impossible  to 
resolve  for  individual  RC  soldiers  and  their  families 
because  the  soldiers  couldn't  be  located.  Failure  to 
track  accurately  the  location  of  IRR  [Individual 
Ready  Reserve]  soldiers  and  individual  TTAD 
[Temporary  Tours  of  Active  Duty]  volunteers  resulted 
in  serious  difficulties  as  theater  commanders 
attempted  to  redeploy  them  within  the  time 
constraints  established  by  Department  of  the  Army. 
"Ghost  hunting"  expeditions  were  organized  to  locate 
these  soldiers  whose  whereabouts  had  been  obscured 
through  a  series  of  "VOCO"  transfers.  Rudimentary 
personnel  support  for  these  RC  soldiers  was 
nonexistent . 


Because  SIDPERS  provided  no  capability  to  retain  as  a 
data  element  the  reservists'  original  units  with  which  they 
mobilized  (and  to  which  they  had  to  be  restored  to 
demobilize),  personnel  units/elements  had  to  resort  to  labor 
intensive  means  to  capture  this  information. 

If  the  soldier  is  reassigned,  their  RC  unit  can 
be  deleted  from  SIDPERS,  thereby  requiring  manual 
screening  of  records  to  identify  the  unit.^^ 

This  really  became  a  challenge  as  many  reservists  were 

reassigned  and  many  of  their  records  had  to  be  screened,  if 

their  records  could  be  located  at  all. 


Without  responsive  and  flexible  automated  systems,  it 
became  guesswork  for  personnel  managers  when  it  came  to 
making  assignment  and  crossleveling  decisions.  There  was 
information  that  the  automated  systems  could  not  provide 
which  should  have  been  considered  when  decisions  were  made. 
For  example,  identification  of  dual  military  couples  may  have 
been  helpful  in  making  mobilization  decisions. 
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Another  example  deals  with  nondeployable  soldiers. 

Had  a  data  element  existed  which  showed  the  status  of  a 
soldier  for  deployment,  then,  once  the  impediment  had  been 
removed,  he/she  could  have  been  sent  to  Southwest  Asia. 

During  Operation  DESERT  SHIELD/STORM  these  soldiers  had  to  be 
tracked  by  labor  intensive  manual  means. 

Similar  consequences • could  be  identified  with  regard 
to  other  unique  informational  requirements  of  the  operation. 
What  really  was  unfortunate  was  that  the  Army  was  able  to 
make  some  fixes  (example:  Deployment  Indicator  Code  in  Jan 
91)  but  the  field,  many  times,  failed  to  implement  the 
changes.  The  most  important  thing  to  understand  from  all  of 
this  is  that  because  of  the  inflexibility  of  personnel 
automation,  decisions  affecting  people’s  lives  were  often 
made  in  the  dark  without  the  benefit  of  sometimes  vital 
information . 

Unfortunately,  for  much  of  the  operation  (not  until 
February  1991)  the  corps  and  the  theater  levels  were  not  able 
to  perform  the  most  basic  automated  strength  management 
support  because  they  lacked  an  automated  role-up  capability. 
This  seriously  impacted  the  effectiveness  of  personnel 
management  at  both  of  these  echelons.  Until  databases  were 
established,  the  corps  or  theater  PERSCOM  had  no  really 
accurate  way  of  accounting  for  the  force,  let  alone 
managing  it.  Even  after  databases  with  roll-up  capability 
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were  set  up,  significant  problems  were  encountered  with 
moving  the  data  to  the  higher  echelons. 

This  situation  resulted  in  missing,  extensively 
delayed,  inaccurate,  and  incomplete  information  at 
brigade  and  higher  levels.... 

Interfaces 

Two  major  impacts  on  the  personnel  community  came 
from  the  inflexibility  of  MOBPERS  and  its  interface  with 
SIDPERS.  First,  because  many  reserve  soldiers  and  units 
reported  to  other  than  their  doctrinally  defined  mobilization 
stations,  automation  clerks  spent  countless  hours  keying  in 
accessioning  data  into  SIDPERS.  This  was  further  compounded 
by  these  clerks  also  having  to  correct  what  MOBPERS  data  had 
been  successfully  added  to  SIDPERS.  Second.,  the  data  that 
was  transferred  through  the  MOBPERS/SIDPERS  interface  was 
insufficient  for  personnel  management  decisions. 

Consequently,  this  left  personnel  managers  without  access 
to  the  full  amount  of  information  they  needed  to  make 
appropriate  assignment/cross leveling/replacement 
decisions.  Because  of  these  problems  encountered  with  this 
interface,  the  Army  never  did  have  full  accountability  of 
reservists  on  active  duty  making  management  next  to 
impossible  at  places  like  Total  Array  PERSCOM  and  the 
Army  Reserve  Personnel  Center  (ARPERCEN),  not  to  mention 
within  the  theater  of  war.^'^ 
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Although  the  SORTS/SIDPERS  interface  allowed  for  the 
use  of  derivative  UICs  for  accounting  for  portions  of  units, 
this  improvisation  also  had  it  drawbacks.  The  theater 
reserve  liaison  office  reported. 

Derivative  unit  identification  codes  (UIC)  were 
used  to  gain  access  to  individuals  within  the  unit 
structures  and  stay  within  the  current  "cap." 

Soldiers  caught  up  in  these  ill-conceived  "remedies" 
became  victims  to  every  possible  personnel  and  pay 
malady . 

The  Desert  STORM  Special  Study  Project  at  Ft.  Leavenworth 
reported  to  a  general  officer  steering  committee  the 
following  concerning  derivative  UICs: 

Because  other  Army  management  systems  [other 
than  SIDPERS]  did  not  recognize  the  derivative  UIC, 
serious  personnel,  pay,  and  logistics  problems 
resulted.  Future  contingency  operations, 
particularly  under  the  restrictive  200K  callup 
provisions,  may  again  require  the  activation  of 
partial  units.  To  preclude  the  problems  encountered 
in  this  operation,  the  Army  must  identify  those  units 
most  likely  to  be  activated  in  increments  and 
document  those  increments  and  the  associated  UIC  in 
MOTE /TD A. 


Without  a  fully  functioning  SIDPERS  interface  with 
postal  operations  throughout  the  operation,  the  workload  for 
postal  units  intensified  as  they  attempting  to  perform  their 
mail  redirect  mission.  This  was  seriously  compounded  by  the 
fact  that  there  was  an  absence  of  postal  units  in  the  force 
structure.  Because  automation  tools  were  not  used  for  much 
of  the  operation,  the  redirect  mission  quickly  grew  beyond 
anyone's  ability  to  respond.  This  resulted  in  serious 
delays  in  mail  delivery,  concerned  family  members 
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back  in  the  states,  and  soldiers  in  Southwest  Asia  wondering 
if  their  mail  would  ever  catch  up  with  them. 

The  lack  of  an  effective  interface  between  SIDPERS 
and  medical  operations  also  created  problems.  Accountability 
was  lost  for  soldiers  evacuated  as  casualties.  Time 
consuming  efforts  were  made  to  locate  evacuated  soldiers. 
Placing  soldiers  as  liaisons  at  the  different  hospitals 
proved  to  be  an  expensive  solution  as  those  soldiers  were 
also  needed  in  their  personnel  units/elements.  Furthermore, 
the  credibility  of  the  personnel  community  to  account  for 
casualties  was  seriously  tarnished. 

In  many  instances  soldiers  would  gain  access  to  a 
phone  and  tell  their  spouses  they  were  in  USAREUR  (US 
Army  Europe].  These  spouses  would  in  turn  blame  Rear 
Detachments  for  withholding  information  from  them. 
Credibility  of  the  Rear  Detachments  suffered 
severely.  In  most  cases  the  Red  Cross  was  not 
involved. 

Fortunately,  there  were  few  casualties  during  the  war. 

Because  there  was  no  automated  system  designed  to 
track  civilians  deployed  to  Southwest  Asia,  accountability 
for  the  civilians  could  only  be  accomplished  through  manual 
means,  if  it  was  accomplished  at  all.  This  lack  of  an 
automated  system  to  account  for  civilians  during  the  war 
has  been  recognized  by  the  highest  levels  of  the  Army. 

Efforts  are  now  underway  to  correct  this  deficiency/ 

O  Q 

oversight . 
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The  interface  between  SIDPERS  and  those  systems 
designed  to  manage  structure  did  not  support  the  operation 
and  consequently  seriously  impacted  the  personnel  community's 
efforts  to  manage  the  force.  ^  The  force  structure  systems 
were  designed  to  support  either  a  peacetime  or  total  war/full 
mobilization  scenario.  Operation  DESERT  STORM  did  not  fit 
into  either  one  of  these  scenarios.  Specifically,  the 
interface  between  SIDPERS  and  The  Army  Authorization  Document 
System  (TAADS)  did  not  have  the  flexibility  to  allow  for  less 
than  full  mobilization.  The  end  result  was  that  many  of  the 
units  supported  the  war  with  only  peacetime  authorizations, 
when  in  fact  many  of  them  needed  to  be  at  higher  strength 
levels  to  adequately  support  the  war  effort. 

Hardware 

Because  many  of  the  reserve  units  did  not  have 
TACCS  equipment,  a  great  deal  of  time  and  effort  went  into 
integrating  these  units  into  the  active  Army  automated 
personnel  systems.  A  corps  support  command  reported. 

This  required  a  massive  effort  to  obtain  TACCS 
equipment  for  those  units  without  it,  to  train  unit 
personnel  on  its  use,  and  to  manually  input  names  and 
unit  information  into  the  data  base.^ 

Those  units  unable  to  get  the  TACCS  equipment  had  to  resort 

to  other  means  to  account  for  their  personnel,  perhaps  with 

other  automation  equipment  or  more  likely  by  manual  means. 

Even  though  many  reserve  units  received  TACCS 
training,  for  the  most  part,  they  still  had  no  idea  how  to 
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operate  their  equipment.  What  training  they  may  have  had  was 
very  limited.  The  Total  Army  PERSCOM  reported. 

Last  minute  efforts  to  provide  TACCS  and 
associated  training  proved  to  be  a  quick  fix  and 
ineffective  in  the  long  term.^^ 

Consequently,  most  of  our  reserve  units  that  had  the  TACCS 

did  not  use  them.  This  seriously  affected  data  accuracy  and 

overall  personnel  automation  support. 

Every  unit  needed  to  use  their  equipment  for  any  hope 
of  having  a  fully  automated  personnel  system  throughout  the 
theater.  But  because  many  units  either  did  not  have  TACCS  or 
did  not  use  their  TACCS,  data  was  not  always  updated. 
Consequently,  the  data  accuracy  at  the  different  reporting 
levels  was  always  suspect. 

The  corps  and  theater  levels  were  impacted  by  the 
lack  of  CTASC  II  equipment.  As  indicated  in  Chapter 
4,  doctrine  requires  the  use  of  CTASC  I Is  at  the  corps 
and  theater  levels.  Unfortunately,  this  equipment  was 
not  fielded  to  either  level  for  use  during  the  operation. 
Because  of  the  enhanced  processing  and  storage  capability 
over  TACCS,  TACCS-Enhanced  equipment  was  used  at  both  corps 
and  theater  levels.  Yet  this  too  proved  inadequate  for  the 
huge  amounts  of  data  that  had  to  be  processed.  Queries  just 
took  too  long,  making  the  system  not  as  responsive  to  the 
system  users  as  is  needed  at  those  levels.  Although  the 
TACCS-Enhanced  equipment  filled  the  void,  CTASC  II  equipment 
still  needs  to  be  fielded  to  the  corps  and  theater  levels. 
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hopefully  before  the  next  major  conflict.  In  fact,  the 
personnel  community  must  also  seriously  consider  whether 
CTASC  II  will  provide  the  needed  capability. 

Communications 

Inadequate  tactical  communications  and  unplanned  for 
transoceanic  data  communications  resulted  in  the  field 
commanders  and  the  Army  leadership  not  having  timely 
visibility  on  needed  information.  Doctrine  only  required 
transoceanic  data  communications  between  the  theater  PERSCOM 
and  the  Total  Army  PERSCOM.  Yet,  during  Operation  DESERT 
STORM  many  personnel  units/elements,  besides  the  theater 
PERSCOM,  had  to  pass  transactions  back  to  their  home  base 
installations  (none  of  this  requirement  was  doctrinally 
planned  for,  creating  a  serious  communications  overload 
requirement  on  the  signal  community) .  Since  it  was  difficult 
for  personnel  units/elements  to  transmit/transfer  data 
between  echelons  within  theater  and  between  theater  and 
CONUS/Europe,  then  personnel  updates  were  not  always  being 
made  in  a  timely  manner,  if  at  all. 

This  lack  of  adequate  communications  impacted 
personnel  accounting  and  strength  reporting  as  well  as  all 
functional  areas.  The  Soldier  Support  Center  explained. 

The  lack  of  adequate  communications  hindered 
critical  replacement,  strength  management,  personnel 
accounting,  strength  reporting,  and  casualty 
functions . 
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Without  adequate  cominunications  then  data  could  not  be 
utilized  and  processed  by  the  various  personnel  functional 
areas  which  completely  rely  on  the  information. 


A  monumental  effort  was  made  by  DA  and  the  signal 
community  in  theater  to  correct  the  communications  problems 
between  corps/theater  levels  and  the  CONUS/Europe  home  base 
support.  By  February  1991  they  were  successful  in  fixing  the 
transoceanic  communication  problems.  Yet,  these  efforts  did 
not  come  soon  enough. 

In  addition  to  the  lack,  of  hardware  and  software 
the  Army  did  not  deploy  an  electronic  link  to  the 
regional  data  centers  to  transmit  and  receive  critical 
personnel  information.  A  link  was  finally  procured  and 
deployed  six  months  into  the  operation.  At  that  stage 
of  the  operation,  however,  personnel  accounting, 
strength  reporting,  and  personnel  management  were 
already  severely  degraded  and  unreliable. 

An  extensive  communications  infrastructure  was  needed  in  the 

conflict  to  ensure  timely  updates  to  databases.  Because  it 

was  largely  nonexistent  or  had  to  be  patched  together  later 

in  the  operation,  the  currency  of  SIDPERS  data  and  its 

accuracy  was  seriously  jeopardized. 


Chapter  6  Conclusions 

There  were  many  problems  encountered  during  Operation 
DESERT  STORM  due  to  the  inability  of  the  personnel  community 
to  satisfy  doctrinal  expectations.  The  disconnect  between 
doctrine  and  practice  resulted  in  serious  backlogs,  increased 
workloads,  extensive  processing  delays,  lost  accountability 
of  soldiers  and  civilians,  out  of  date  data,  incorrect  data. 
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system  nonresponsiveness,  reporting  inconsistencies, 
ineffective  personnel  management,  and  most  important  degraded 
service  to  the  soldier.  These  problems  seriously  jeopardized 
the  utility  of  personnel  automation  as  a  whole.  With  all  the 
problems  that  were  encountered,  it  is  no  wonder  that  to  this 
day  the  personnel  community  is  trying  to  sort  out  the  status 
of  tens  of  thousands  of  soldiers  who  participated  in  the  war. 
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CHAPTER  6 
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CHAPTER  7 


THESIS  CONCLUSIONS 

There  is  no  question  that,  during  Operation  DESERT 
STORM,  the  personnel  conununity  utilized  personnel  automation 
in  support  of  personnel  accounting  and  strength  reporting 
much  differently  than  doctrine  anticipated.  Consequently, 
there  were  some  serious  problems  which  affected  the  ability 
of  the  personnel  community  to  provide  quality  personnel 
service  support.  The  purpose  of  this  chapter  is  to  summarize 
the  differences  between  doctrine  and  practice,  to  summarize 
the  consequences  or  problems  that  resulted,  and  finally,  to 
present  some  general  recommendations/considerations  for  those 
who  will  be  working  to  find  the  solutions  to  the  problems 
encountered. 


Summary  of  Doctrine  vs .  Practice 

There  were  several  major  differences  between 
doctrinal  expectations  and  how  the  personnel  community 
actually  performed  personnel  automation  during  Operation 
DESERT  STORM.  Functional  expectations  generally  exceeded 
what  doctrine  anticipated.  Personnel  units/elements 
continued  using/maintaining  peacetime  software  even  though 
doctrine  intended  the  use  of  streamlined,  wartime  software. 
Existing  interfaces  between  automated  systems  were  generally 
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not  flexible  or  timely  enough  to  support  the  operation, 
contrary  to  expectation.  The  hardware  had  not  been  fielded 
everywhere  intended  nor  was  it  always  properly  used  where  it 
was  fielded.  And  finally,  communications  initially  was 
virtually  nonexistent  and  had  to  be  patched  together,  even 
though  personnel  doctrine  had  intended  it  to  be  there. 

Summary  of  Impacts  from  Noncompliance  with  Doctrine 

The  differences  between  doctrine  and  practice 
impacted  the  ability  of  the  personnel  community  to  account 
for  the  force  and  provide  quality  personnel  service  support. 
With  functional  expectations  being  excessive,  personnel 
units/elements  experienced  increased  workloads  and  serious 
backlogs.  Peacetime  software  required  personnel 
elements/units  to  maintain  more  data,  adding  to  their 
workload.  Because  many  units  had  difficulty  using  the 
software  available,  accuracy  of  data  was  jeopardized. 
Inflexible  interfaces  resulted  in  the  manual  loading  of 
data,  adding  to  the  workload,  especially  at  mobilization 
stations.  In  some  cases,  the  lack  of  interfaces  resulted  in 
lost  accountability  of  those  deployed  to  Southwest  Asia. 

Lack  of  sufficient  hardware  for  personnel  units/eleraents 
seriously  affected  data  accuracy  and  overall  personnel 
automation  support.  And  finally,  without  adequate 
communications,  personnel  units/elements  had  to  resort  to 
other  means  of  passing  transactions  such  as  by  mail  or  by 
courier.  This  resulted  in  lengthy  delays  and  directly 
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impacted  data  currency.  Overall,  personnel  management 
decisions  suffered  from  outdated,  incorrect  data. 

Recommendations /Considerations 

There  are  several  recommendations  that  should  be 
considered  by  those  who  will  work  on  finding  the  solutions  to 
the  personnel  automation  problems  encountered  during  the  war. 
These  recommendations/considerations  are  listed  below. 

The  personnel  community  needs  to  re-examine  its 
personnel  automation  doctrine.  Our  wartime  doctrine  can  no 
longer  be  oriented  to  a  European  or  total  war  scenario,  but 
must  provide  for  scenarios  of  less  than  full  mobilization. 
Doctrine  must  describe  the  data  flow  for  personnel 
accounting  and  strength  reporting  as  it  transitions  from  an 
immature  theater,  with  few  personnel  assets,  to  a  theater 
with  the  full  range  of  personnel  units/eleraents  to  include 
a  theater  PERSCOM.  Doctrine  needs  to  define  what  data  and 
reports  are  required  at  each  echelon.  Doctrine  needs  to 
define  how  to  handle  the  reserve  component,  especially  in 
scenarios  of  less  than  full  mobilization.  Finally, 
doctrine  needs  to  define  how  to  actually  deploy  the  force 
and  then  how  to  redeploy  the  force  back  to  their  home 
stations  after  the  conflict  is  over.  Overall,  the  doctrine 
must  allow  greater  flexibility  and  more  options  for  the 
personnel  community. 
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All  efforts  should  be  expended  to  streamline  the 
workload  for  personnel  units/elements  deployed  in  war.  Their 
focus  must  be  on  supporting  the  war  effort  and  not  on 
maintaining  peacetime  systems  and  functions.  If  peacetime 
functionality  must  be  maintained,  then  it  should  be  done 
exclusively  by  the  CONUS  sustaining  base,  not  dependent  on 
the  units  deployed  in  a  theater  of  war  to  perform  any  of  the 
peacetime  missions.  During  Operation  DESERT  STORM,  even 
though  the  forces  in  Southwest  Asia  were  facing  a  potential 
mid  to  high  intensity  conflict  against  the  fourth  largest 
Army  in  the  world  and  with  an  anticipated  30,000+  American 
casualties,  personnel  units/elements  struggled  to  support 
peacetime  requirements. 

Likewise,  units  deployed  to  fight  a  war  should  be 
filled  and  managed  at  their  wartime  required  strengths.  If 
this  is  not  possible,  then  the  automated  personnel  and 
structure  systems  must  be  adapted  so  that  they  will  allow  the 
transition,  by  unit,  between  the  different  levels  of 
authorized  strengths  to  wartime  required  strength  as  the 
conflict  escalates  in  intensity. 

An  adequate  automated  task  force  capability  must  be 
developed  for  field  use.  Task  forcing  is  now  the  norm 
and  will  likely  increase  as  different  types  of  units  become 
more  and  more  integrated  on  the  battlefield. 
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There  needs  to  be  a  balanced  deployment  of  units  at 
all  echelons.  If  this  is  not  possible  due  to  the  need  to 
front load  combat  units,  then  the  Army  must,  at  least, 
identify  the  minimum  critical  combat  service  support  (CSS) 
forces  required  for  early  deployment. 

Once  it  is  determined  that  a  theater  personnel 
command  (PERSCOM)  is  needed,  it  must  be  deployed/organized 
rapidly.  A  reserve  theater  PERSCOM  structure  (already  in  the 
force  structure)  could  be  activated  in  the  continental  United 
States  (CONUS)  initially,  begin  the  process  of  establishing 
theater  policies/procedures/direction,  and  then  incrementally 
deploy  and  transition  to  a  theater  location. 

The  Army  should  carefully  review  the  need  for  a  total 
integrated  personnel  system.  Granted,  Congress  has  halted 
efforts  toward  that  end  before.  Nevertheless,  much  of  the 
personnel  functionality  between  the  three  components  is  the 
same  and  could  be  standardized  and  integrated.  Under¬ 
standably,  this  may  never  be  possible.  Even  so,  the 
personnel  community  must  not  halt  efforts  to  establish  a 
single  source  database  between  components  with 
standardized  data  elements  (the  Total  Army  Personnel 
database  -  TAPDB). 

A  deployable  wartime  Standard  Installation/Division 
Personnel  System  (SIDPERS)  package  is  needed  and  should  be 
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used.  If  the  current  SIDPERS-Wartime  software  is  inadequate, 
then  it  must  be  redesigned  or  replaced. 

The  Command  and  Control  Strength  Reporting  System 
(C2SRS)  software  needs  revision.  Currently,  it  is  too 
complex  and  cumbersome  to  use.  The  software  must  be  simple 
or  the  field  just  will  not  use  it,  as  indicated  by  the 
experience  of  the  Gulf  War.  It  must  also  be  designed  to  work 
with  the  SIDPERS-Wartime  software. 

SIDPERS  must  allow  the  ability  for  the  field  to 
track  the  different  categories  of  reservists  activated.  In 
most  Cases,  it  is  the  field,  not  the  top  of  the  system,  which 
makes  the  crossleveling/assignment  decisions.  This 
information  is  especially  critical  for  redeployment  purposes. 

Personnel  automation  must  allow  for  greater 
flexibility  and  responsiveness  to  the  system  users.  The 
personnel  community  must  be  able  to  tailor  reports  and 
outputs  to  meet  their  unique  needs.  Query  capability  is  a 
must.  Nevertheless,  there  is  a  need  for  standardization  and 
consistency  throughout  the  Army,  but  this  need  must  not  so 
completely  restrict  system  users  that  they  feel  compelled  to 
seek  out  other  automation  possibilities  readily  available  on 
commercial  markets. 

When  the  Department  of  the  Army  (DA)  resolves  system 
shortcomings,  then  the  field  needs  to  implement  the  changes. 
During  Operation  DESERT  STORM,  there  were  occasions  when 
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problems  could  have  been  solved  if  only  the  field  had 
implemented  the  changes  identified  by  DA. 

Software  needs  to  be  developed  and  fielded  which 
would  allow  for  a  corps/theater  roll-up  capability.  A  good 
start  would  be  to  work  with  the  Soldier  Support  Center 
corps  prototype  software. 

For  future  conflicts  requiring  echelon  above 
corps  units,  the  Army  should  seriously  consider  allowing  the 
processing  of  SIDPERS  transactions  within  the  theater 
itself  and  not  thousands  of  miles  away  by  many  different 
activities . 

The  interface  between  the  Mobilization  Personnel 
System  (MOBPERS)  and  SIDPERS  must  be  improved.  If  possible, 
MOBPERS  must  be  enhanced  to  allow  for  the  accessioning  of 
soldiers  at  other  than  their  doctrinally  defined  mobilization 
stations.  Adding  data  elements  to  the  MOBPERS  accessioning 
record  should  also  be  considered.  The  best  solution  would  be 
to  create  a  central  mobilization  database  from  which  the 
mobilization  stations  could  pull  down  accessioning  data. 

Improvement  needs  to  be  made  with  the  interface 
between  the  Status  of  Resources  and  Training  System  (SORTS) 
and  SIDPERS.  Although  the  use  of  derivative  unit 
identification  codes  (UICs)  proved  useful  for  the  personnel 
community,  the  Army  must  identify  those  units  most  likely  to 
be  deployed  incrementally  and  document  each  increment  with 
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its  own  unique  UIC.  The  same  is  true  for  patient/replacement 
holding  detachments.  Finally,  SORTS  must  improve  it's 
timeliness  or  currency  problems.  These  problems  directly 
impact  the  automated  personnel  systems. 

The  personnel  community  needs  to  develop  and  field  an 
automated  postal  locator  with  SIDPERS  interface.  A  good 
start  would  be  to  look  at  those  systems  improvised  during 
the  war. 


There  must  be  automated  accountability  for  civilian 
personnel  deployed  to  a  theater  of  war.  Either  the  Automated 
Civilian  Personnel  System  (ACPERS)  must  develop  a  deployable 
software  package  or  SIDPERS  must  be  enhanced  to  accommodate 
civilian  accountability.  The  latter  may  be  more  difficult  to 
achieve  in  the  short  term  as  SIDPERS  would  require  massive 
revision . 

An  automated  interface  between  SIDPERS  and 
the  Theater  Army  Medical  Management  Information  System 
(TAMMIS)  must  be  established.  This  is  critical  to  ensure 
that  accountability  is  not  lost  when  casualties  are  evacuated 
to  the  hospitals. 

As  long  as  the  Department  of  the  Army  keeps  the 
automation  architecture  closed,  then  the  Tactical  Combat 
Service  Support  Computer  System  (TACCS)  needs  to  be  fielded 
to  the  rest  of  the  reserve  component  units.  What  is 
important  is  that  all  units,  both  active  and  reserve,  must 
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have  the  hardware  to  perforin  personnel  accounting  and 
strength  reporting.  Furthermore,  once  initial  training  is 
completed  on  the  hardware,  then  all  units  must  retain  their 
proficiency  through  sustainment  training,  also,  all 
mobilization  stations  need  to  have  TACCS  equipment,  or 
comparable  equipment,  for  their  activating  units  to  use  or 
train  on  while  their  equipment  is  shipped. 

The  Corps/Theater  ADP  Service  Center  II  (CTASC  II) 
needs  to  be  fielded  to  the  corps  and  theater  levels.  But 
before  the  personnel  community  commits  itself  to  the  CTASC 
II,  it  needs  to  ensure  that  CTASC  II  will  provide  the 
capability  that  is  needed.  In  the  meantime,  if  CTASC  I  is 
available,  then  it  should  be  used. 

CSS  units  are  practically  void  of  tactical 
communications  which  could  be  used  to  transmit  data.  This 
shortfall  in  communications  must  be  addressed.  The  Army  must 
fund  the  movement  of  data  between  echelons  or  the  same 
problems  will  resurface  during  the  next  conflict. 

The  personnel  community,  in  coordination  with  the 
signal  community,  must  resolve  what  is  needed  for  theater  to 
CONUS  communications.  Then  doctrine  will  have  to  be  changed 
and  funding  be  made  available  to  satisfy  any  new 
requirements . 

Many  of  the  problems  identified  in  this  thesis  may  be 
solved  through  the  application  of  new  technologies.  This  is 
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particularly  so  with  the  problems  encountered  with  hardware 
and  communications.  The  Army  should  give  greater 
consideration  to  using  nondevelopmental  items  (NDI). 

Although  Army  developed  equipment  may  be  ruggidized,  it  is 
also  far  more  expensive  to  replace  and  usually  behind  the 
times  when  it  is  finally  fielded.  TACCS  for  example  has  been 
fielded  for  years  and  now  with  funding  constraints,  it  is 
questionable  whether  the  rest  of  the  reserve  component  will 
ever  get  their  TACCS  equipment.  In  the  meantime,  laptop 
equipment  is  sold  on  the  market  with  comparable  capabilities 
and  at  much  lower  prices.  It  is  time  to  open  the 
architecture  to  allow  greater  flexibility  and  diversity.  The 
technology  today  allows  for  that  possibility. 

Chapter  2  Conclusions 

With  an  understanding  of  how  personnel  automation 
was  practiced  during  Operation  DESERT  STORM,  how  it  varied 
from  doctrine,  and  how  these  variations  impacted  personnel 
automation  support,  the  personnel  community  may  now  reassess 
its  automation  capabilities  and  improve  upon  them.  The 
personnel  community  will  no  doubt  recover  from  the  challenges 
faced  during  Operation  DESERT  STORM.  The  problems  identified 
in  this  thesis  should  be  analyzed  for  possible  solutions. 

The  Army  may  then  incorporate  these  solutions  into  current 
systems  through  enhancements  as  well  as  through  the  design 
and  development  of  future  personnel  automation  projects. 

With  doctrine  changed  to  incorporate  these  solutions,  the 
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personnel  community  must  be  disciplined  enough  to  comply 
with  it.  In  conclusion,  the  personnel  community  must  learn 
from  the  problems  encountered  during  Operation  DESERT  STORM 
and  build  a  better  automated  personnel  system  to  meet  the 
challenges  of  tomorrow's  wars. 


110 


BIBLIOGRAPHY 


1.  Government  Publications 

US  Army.  ^  11-33,  Army  Lessons  Learned  Program:  System 

Development  and  Application .  Washington,  DC:  Department 
of  the  Army,  October  1989. 

US  Army.  FM  100-10 ,  Combat  Service  Support .  Washington,  DC: 
Department  of  the  Army,  February  1988. 

US  Army.  ^  600-8 ,  Military  Personnel  Management .  Washington, 
DC:  Department  of  the  Army,  1989. 

US  Army.  DA  PAM  25-6 ,  Configuration  Management  for  Automated 
Information  Systems .  Washington  DC:  Department  of  the 
Army ,  1991. 

US  Army.  FM  12-6 ,  Personnel  Doctrine.  Washington,  DC: 
Department  of  the  Army,  August  1989. 


2.  Newspapers  and  Magazines 

"Forces  Committed."  Military  Review  Vol.  LXXI-9  (September 
1991):  80-81. 

US  Army,  Center  for  Army  Lessons  Learned  (CALL).  "Combat 

Service  Support  (CSS)."  Newsletter  Special  Edition,  No  90- 
11 ,  Dec  90 ,  Getting  to  the  Desert ,  Deployment  and  Selective 
Callup  Lessons ,  DESERT  SHIELD.  Ft.  Leavenworth,  KS :  US 
Army  Combined  Arms  Command,  1990. 

Yeosock,  John  J.,  Lieutenant  General  US  Army.  "Army 

Operations  in  the  Gulf  Theater."  Military  Review  Vol. 
LXXI-9  (September  1991):  3-15. 


3.  Unpublished  Government  Reports 

The  Joint  Staff.  Joint  Staff  Joint  Deployment  Report . 
Washington,  DC,  February  1991. 

US  Array,  Center  for  Army  Lessons  Learned  (CALL) .  Army 

Lessons  Learned  from  Operation  DESERT  SHI ELD /STORM  (over 
6,700  lessons  learned  on  data  base).  Ft.  Leavenworth, 
KS:  Department  of  the  Army,  August  1991. 


Ill 


US  Array  Corabined  Arras  Support  Comraand.  Operation  Desert 

SHIELD/STORM  Observations  and  Related  Data .  Ft.  Lee,  VA: 
Departraent  of  the  Array,  August  1991, 

US  Array  Concepts  Analysis  Agency,  ODCOSPS,  HQDA.  HQDA 
DESERT  SHI ELD /DESERT  STORM  After  Action  Report  ( U ) 

Vol.  II:  Main  Report.  Washington,  DC:  Departraent  of 
the  Array,  September  1991. 

US  Array.  CTASC  II  Basis  of  Issue  Plan  ( BOIP ) .  Washington, 
DC:  Departraent  of  the  Army,  date  unknown. 

US  Array,  Desert  Storm  Special  Study  Project  (CALL).  General 
(  if icer  Steering  Coraraittee .  Ft.  Leavenworth,  KS : 
department  of  the  Army,  July  1991. 

US  Army,  Headquarters,  Department  of  the  Array.  HOS . 

Departraent  of  the  Array  DESERT  SHIELD/DESERT  STORM  After 
Action  Report .  Washington,  DC:  Department  of  the  Army, 
June  1991. 

US  Army,  Headquarters,  USARCENT.  USARCENT  AA  Report  (28 
Vols.).  Ft.  Leavenworth,  KS:  Department  of  the  Army, 
August  1991. 

US  Array,  Headquarters,  USAREUR.  USAREUR  DESERT  SHIELD/DESERT 
STORM  Lessons  Learned.  Ft.  Leavenworth,  KS:  Department 
of  the  Array,  June  1991. 

US  Army, Headquarters,  USAREUR.  USAREUR  Operations  DESERT 
STORM  &  DESERT  SHIELD  Theater-level  Observations .  Ft. 
Leavenworth,  KS:  Department  of  the  Array,  June  1991. 

US  Array,  Headquarters,  1st  Corps  Support  Comraand.  1st  Corps 
Support  Command  Operation  DESERT  SHIELD/DESERT  STORM 
After  Action  Review.  Ft.  Leavenworth,  KS :  Departraent  of 
the  Array,  November  1991. 

US  Array,  Headquarters,  3d  ACR.  3d  ACR  Operation  DESERT 

SHIELD/STORM  After  Action  Report .  Ft.  Leavenworth,  KS : 
Department  of  the  Army,  August  1991. 

US  Array,  Headquarters,  3AD.  3AD  PS  Summary  (9  Vols.).  Ft. 
Leavenworth,  KS :  Department  of  the  Army,  unknown. 

US  Army,  Headquarters,  3rd  Army.  3rd  Array  After  Action 

Report  (2  Vols.).  Ft.  Leavenworth,  KS :  Department  of 
the  Army,  unknown. 

US  Array,  Headquarters,  VII  Corps.  VII  Corps  Desert  Campaign 
After  Action  Report  (28  Vols.).  Ft.  Leavenworth,  KS : 
Department  of  the  Array,  August  1991. 


112 


US  Army,  Headquarters,  82d  AB  Division.  82d  AB  Division 

After  Action  Report  Operation  DESERT  SHIELD/STORM.  Ft. 
Leavenworth,  KS:  Department  of  the  Army,  May  1991. 

US  Army,  Headquarters,  101st  Division.  101st  Division  AAR 
Operation  DESERT  SHI ELD /DESERT  STORM.  Ft.  Leavenworth, 
KS:  Department  of  the  Army,  June  91. 

US  Army  National  Guard.  Army  National  Guard  After  Action 
Report  Operation  DESERT  SHIELD  Operation  DESERT  STORM. 
Washington,  DC:  Departments  of  the  Army  and  the  Air 
Force,  June  1991. 

US  Army,  Office  of  the  Chief,  Army  Reserve.  Chief ,  Army 
Reserve  Comments  to  Draft  DESERT  STORM  Special  Study 
Project  (CALL).  Ft.  Leavenworth,  KS :  Department  of  the 
Army,  September  1991. 

US  Army,  Office  of  the  Deputy  Chief  of  Staff  for  Personnel 
(ODCSPER) .  ODCSPER  Mobilization  Automation  Task  Force 
Action  Plan .  Washington,  DC:  Department  of  the  Army, 
August  1991. 

US  Army,  Reserve  Component  Liaison  Office,  United  States  Army 
Forces  Central  Command.  United  States  Army  Forces 
Central  Command  Reserve  Component  Liaison  Office  Gulf  War 
After  Action  Report .  Ft.  Leavenworth,  KS:  Department  of 
the  Army,  unknown. 

US  Army  Soldier  Support  Center.  Operation  DESERT 

SHIELD/STORM  After  Action  Review.  Ft  Benjamin  Harrison, 
IN:  Department  of  the  Army,  August  1991. 

US  Army,  US  Total  Army  Personnel  Comma. d  (PERSCOM) .  After 

Action  Report  Operation  DESERT  SHIELD /STORM.  Alexandria, 
VA:  Department  of  the  Army,  August  1991. 

US  Forces  Command.  Interim  CINCFOR  DESERT  SHIELD/STORM  ( PS ) 
After  Action  Report ,  Phase  I ,  Mobilization/Deplovment . 

Ft.  Leavenworth,  KS:  Department  of  the  Army,  July  1991. 

US  Military  Traffic  Management  Command.  Military  Traffic 
Management  Command  Lessons  Learned  DESERT  SHIELD .  Ft. 
Leavenworth,  KS:  Department  of  the  Army,  August  1991. 


4.  Briefings/Working  Papers 

Revell,  Joseph  L.  Revell,  LTC.  Memo  For  Chief,  CALL 
(Forward),  "Executive  Summary  (Personnel  Service 
Support)".  Ft.  Leavenworth,  KS:  Department  of  the  Army, 
Undated. 


113 


Notes  in 


Swain,  Richard  M.,  II,  COL.  Thesis  review  notes, 
author's  possession,  February  1992. 

US  Army,  Field  Systems  Directorate,  US  Total  Army  Personnel 
Command.  Briefing  -  DESERT  SHIELD  Strength 
Account inq/Reporting.  Alexandria,  VA:  Department  of  the 
Army,  September  1990. 

US  Army,  Field  Systems  Directorate,  US  Total  Army  Personnel 
Command.  Miscellaneous  working  papers.  Alexandria,  VA: 
Department  of  the  Army,  1991. 

US  Army,  Headquarters,  10th  PERSCOM.  Briefing  -  PERSCOM  ARR. 
Ft.  Leavenworth,  KS:  Department  of  the  Army,  1991. 

US  Army,  ODCSPER.  Briefing  -  ODCSPER  Mobilization  Automation 
Task  Force  Action  Plan .  Washington,  DC:  Department  of  the 
Army,  August  1991. 

US  Army,  The  Adjutant  General  Directorate,  US  Total  Army 
Personnel  Command.  Briefing  -  Transition  Processing . 
Alexandria,  VA:  Department  of  the  Army,  1991. 


5.  Interviews 

Adair,  Lawrence  J.,  COL,  Field  Systems  Directorate,  US  Total 
Array  Personnel  Command  (PERSCOM) .  Telephone  interview 
conducted  by  author.  Notes  of  interview  in  author's 
possession,  1  November  1991. 

Brady,  John  E.,  GM14,  Operations  Division,  Field  Systems 

Directorate,  PERSCOM.  Telephone  interviews  conducted  by 
author.  Notes  of  interviews  in  author's  possession, 

21  February  1992,  17  &  18  March  1992,  23  April  1992. 

Bukowski,  Victor,  LTC,  HQDA  DCSPER  ( DAPE-ZXI-AA .  Telephone 
interview  conducted  by  author.  Notes  of  interview 
in  author's  possession,  5  March  1992. 

Graves,  Emily  B.,  CPT,  Strength  Accounting,  10th  PERSCOM. 
Telephone  interview  conducted  by  author.  Notes  of 
interview  in  author's  possession,  4  &  5  March  1992. 

Ithier,  Oscar,  SFC,  XVIII  Airborne  Corps  Automation  Branch. 
Telephone  interview  conducted  by  author.  Notes  of 
interview  in  author's  possession,  23  March  1992. 

Meucci,  James  R. ,  MAJ,  BDE  SI,  197th  IN  BDE .  Interview 
conducted  by  author.  Notes  of  interview  in  author's 
possession,  25  February  1992. 


114 


Nicholas,  Sam,  SGM,  ARGENT  Reserve  Liaison  Office. 

Telephone  interview  conducted  by  author.  Notes  of 
interview  in  author's  possession,  18  March  1992. 

Palmer,  Christine,  CW3,  344th  Data  Processing  Unit  (DPU). 
Telephone  interview  conducted  by  author.  Notes  of 
interview  in  author's  possession,  5  March  1992. 

Proctor,  Larry,  LTC,  344th  DPU.  Telephone  interview 

conducted  by  author.  Notes  of  interview  in  author's 
possession,  23  March  1992. 

Turner,  William  M.,  SGM,  24th  PSC,  24th  Infantry  Division. 
Telephone  interview  conducted  by  author.  Notes  of 
interview  in  author's  possession,  24  March  1992. 


115 


INITIAL  DISTRIBUTION  LIST 


1.  Adjutant  General  School, 

Soldier  Support  Institute 
Soldier  Support  Center 

Fort  Benjamin  Harrison,  Indiana  46216 

2 .  Combined  Arms  Research  Library 

U.S.  Army  Command  and  General  Staff  College 
Fort  Leavenworth,  Kansas  66027-6900 

3.  Defense  Technical  Information  Center 
Cameron  Station 

Alexandria,  Virginia  22314 

4.  Field  Systems  Directorate 

U.S.  Total  Army  Personnel  Command 
200  Stoval  Street 
Alexandria,  Virginia  22332 

5.  Manning  The  Force  Automation  Architecture  Office  (MTFA^) 
Office  of  the  Deputy  Chief  of  Staff  for  Personnel 

200  Stoval  Street 
Alexandria,  Virginia  22332 

6.  SIDPERS-3  Project  Manager 
Information  Systems  Engineering  Command 
200  Stoval  Street 

Alexandria,  Virginia  22332 

7.  LTC  Barton  L.  Pearl  (Committee  Chairman) 

Department  of  Sustainment  and  Resourcing 
USACGSC 

Fort  Leavenworth,  Kansas  66027-6900 

8.  MAJ  Richard  M.  Caldwell  (Committee  Member) 

Department  of  Sustainment  and  Resourcing 
USACGSC 

Fort  Leavenworth,  Kansas  66027-6900 

9.  COL  Richard  M.  Swain  II  (Committee  Member) 

Combat  Studies  Institute 

USACGSC 

Fort  Leavenworth,  Kansas  66027-6900 


116 


